[Joe, Alex]

This morning I began the process of bringing our copy of the CDS code up to date to the version installed at Livingston. The motivation was to get fixes to various parts, among others such as the oscillator part.   This would mean cleaning up front end model .mdl files without having to pass clk, sin, cos channels for every optic through 3 layers of simulink boxes.

I also began the process of using a similar startup method, which involved creating /etc/init.d/ start and stop scripts for the various processes which get run on the front ends, including awgtpman and mx_streams.  This allows the monitor software called monit to remotely restart those processes or provide a web page with a real time status of those processes.  A cleaner rc.local file utilizing sub-scripts was also adapted.

I did some testing of the new codes on c1iscey.  This testing showed a problem with the timing part of the code, with cycles going very long.  We think it has something to do with the code not accounting for the fact that we do not have IRIG-B timing cards in the IO chassis providing GPS time, which the sites do have.  We rely on the computer clock and ntpd.

At the moment, we've reverted to svn revision 2174 of the CDS code, and I've put the previously working version of the c1scy and c1x05 (running on the c1iscey computer) back. Its from the /opt/rtcds/caltech/c1/target/c1x05/c1x05_11014_163146 directory.  I've put the old rc.local file back in /diskless/root/etc/ directory on the fb machine.  Currently running code on the other front end computers was not touched.

The south arm labels were changed from y to x to reflect reality.

So racks, manual disconnects and breakers now have their actual name. The east arm will be changed over tomorrow.

Please remove incorrect labels if you see any !

I can not find 1X4 breaker so it will be  traced.

[Larisa and Jenne]

A few weeks ago (on the 28th of January) I had tried to measure the quantum efficiency of one quadrant of the WFS as a function of angle.  However, Rana pointed out that I was a spaz, and had forgotten to put a lens in front of the laser.  Why I forgot when doing the measurement as a function of angle, but I had remembered while doing it at normal incidence for all of the quadrants, who knows?

Anyhow, Larisa measured the quantum efficiency today.  She used WFS2, quadrant 1 (totally oil-free), since that was easier than WFS1.  She also used the Jenne Laser (with a lens), since it's more stable and less crappy than the CrystaLasers.  We put a 50 Ohm terminator on the RF input of the Jenne Laser, since we weren't doing a swept sine measurement.  Again, the Ophir power meter was used to measure the power incident on the diode, and the reflected power, and the difference between them was used as the power absorbed by the diode for the quantum efficiency measurement.  A voltmeter was used to measure the output of the diode, and then converted to current as in the quote below. 

Still on the to-do list:  Replace the WFS2 diode.  See if we have one around, otherwise order one.  Align beams onto WFS so we can turn on the servo.

QE = (h*c)/(lambda*e) * (I/P)

Where I = (Volts from Pin1 to GND)/2 /500ohms
P = Power from laser - power reflected from diode.
h, c, e are the natural constants, and lambda is 1064nm.

Also, I/P = Responsivity

Larissa is going to put her data and plots into the elog shortly....

It turns out there are no reasonable signal from the segment 1 on the IP_ANG QPD.

For right now I can still use it as a funny QPD, but I absolutely need somebody to check and fix it in a daytime.

The #3 enclosure door was removed for the carpenter shop this morning. They will make 5 full size doors with window on each.

TEMPORARY aluminum sheet is clamped into its place. This sheet should not be removed till new doors arrive.

The inside Formica color will be changed from white to black to reduce the green scattering.

  I am concentrating on the RF system just now and will be attending to the RF PDs one by one.  Also plan to work on some of the simpler CDS problems when I overlap with Joe.  Will be available for helping out with the beam alignment.

There were several parts in this box which did not have shunting capacitors across their input power lines.  Only the four RF amps (ZHL-2) had them.

I soldered two capacitors (100 microF electrolytic and 150pF dipped mica) across the power supply lines of each of the following units:  11MHz oscillator, 29.5 MHz oscillator,  Wenzel 5x frequency multiplier and the 12x RF amplifier (ZHL-1HAD).

It was quite difficult to reach the power inputs of these units as some of them were very close to the inner walls of the box.  To access them I undid the front panel and found that there were several very taut RF cables which prevented me from moving the front panel even a little.

I had to undo some of the RF cables and swap them around till I found a solution in which all of them had some slack.  At the end I checked to make sure that the wiring is in accordance with the schematic present here.

I propose to use C1:ALS-xxx_xxx for the names of the green related channels, instead of GCV, GCX, GCY, GFD...

Like C1:SUS or C1:LSC, we name the channels by the subsystems first, then probably we can specify the place.

We can keep the names of the processes as they are now.

This is just a listing of  CDS problems I still notice today:

1. MC2-MCL button was left ON due to BURT failure. This, of course, screws up our Green locking investigations because of the unintended feedback. Please fix the BURT/button issue.

2. The GCV - FB0 status is RED. I guess this means there's something wrong? Its really a bad idea to have a bunch of whited out or falsely red indicators. No one will ever use these or trust these in the future.
3. MC1/2/3 Lockins are all white. Also, the MODE switches for the dewhitening are all white.
4. Is the MC SIDE coil dewhitening filter synced with anything? It doesn't seem to switch anything. Maybe the dewhite indicators at the top right of the SUS screens can be made to show the state of the binary output instead of just the digital filter
5. MC WFS is all still broken. We need a volunteer to take this on - align beams, replace diodes, fix code/screens.

We hooked up the VCO Driver output to the MFD. We adjusted the levels with attenuators to match up to the Level 7 mixer that's being used.

The mixer the input to the SR560 is going in to the XARM_COARSE_OUT channel and the SR560 (AC coupled, Low Noise, G=1000, LP@1kHz) 600 Ohm output goes into XARM_FINE_OUT.

We calibrated these channels by putting in a 10 mVpp sine wave at 0.22 Hz into the Wideband Input of the VCO Driver box (which has been calibrated to have 1.75 MHz/V for f < 1.6 Hz). This should correspond to 17.5 kHz_pp.

To increase the sensitivity, we also added a 140 ft. BNC cable to the setup. We also added some extra short cable to make the overall phase shift be ~90 deg and zero out the mixer output.

I used the time series data in DTT to then calibrate the channels by changing the GAIN field in their filter modules. So now the DAQ channels are both calibrated as 1 count/Hz.

I found that the ADC channels for IP_ANG had been assigned to a wrong machine.

IP_ANG is supposed to be acquired at c1auxey (east end), but actually it had been at c1auxex (south end).

This is the reason why we couldn't see any signals from IP_ANG.

So I fixed it by editing the db files (i.e. ETMXaux.db and ETMYaux.db). Now it seems working fine.

This mistake obviously came from the X-Y name swapping business. Something else might be still wrong.

It is 0.375 mW as in the calculation.  The total diode output is just 1mW and it is divided with a 50/50 beam splitter...  There are a couple of lenses along the way which may account for the ~12% loss. 

I used a handheld multimeter to measure the output.  

The amounts of the X arm's beam off-centering have been measured by the A2L technique.

So now we are able to start aligning the IR beam axis in a quantitative way.

(motivation)

 Since we saw big residual motions at 1 Hz, 16 Hz on both the green beat note signal and the IR PDH signal (see #4268 and #4211),

we are suspecting that these noise come from an angle to length coupling.

In order to minimize the angle to length coupling, one thing we can do is to bring the beam spots to the center of ITMX and ETMX more precisely.

To do it, we have to quantitatively know how well the beam spots are on the center of the optics. Therefore I started measuring the amount of the beam off-centering.

(method)

 The A2L technique was used to measure the off-centering with the real-time lockin system, which has been recently embedded in the real-time code by Joe (see #4265).

The idea is the same as Yuta did before (see #3863).

But this time the excitation signal from the real-time oscillator was injected directly to the coil matrix on either ITMX or ETMX, at 18.13 Hz with the amplitude of about 400 cnt.

When the IR laser stays locked to the X arm, the LSC feedback signal is demodulated with the oscillator signal.

This demodulated signal gives the amount of the off-centering.

For this purpose I modified Yuta's A2L script such that we can use it also for the X arm.

(results)

 I obtained the following values:

     - ETMX

         PIT  = -1.61 mm

         YAW =  -0.918 mm

    - ITMX

         PIT = -3.76 mm

        YAW = -2.24 mm

I used the same calibration factor as that of Koji calculated (see #3020) for MC, in order to convert the results from the coil gain to the off-centering.

These values are consistent with the spots appearing on the CCD monitors.

Suresh is saying 375mW and 0.375mW. Let's wait for his update of the actual power.

Also he is not using EPICS, there may be the factor of two missing for now.

375 mW is way too much light. We must never put more than 100 mW on any of these diodes. We don't want to blow up more diodes like we did with the WFS. The InGaAs diodes often show an excess dark noise before they finally let go and completely fail. This one may show excess during the shot noise testing.

We should ensure that the beam paths are engineered so that none of these new detectors ever sees such high light levels.

The DC path should be made to let us see a 10V from the differential EPICS readout when there is 100 mA of photocurrent (i.e. an effective 100 Ohms transimpedance):

0.1 A  * 10 V/A * 5 V/V * 2V/V

The last factor of 2 is from the single to differential conversion.

If we really only get 15 mV from 375 mW, then this diode or the circuit is broken.

A new photodiode ( Perkin and Elmer Model no. C30642GH Sl No.1526) has been installed in the place of the old photodiode.  The datasheet of this model is attached. 

The 68pF capacitor which was present in parallel with the photodiode has been removed.  Here is a picture of the PCB ( in all its gory detail!) and the photodiode after replacement.

I also checked to see if we have a DC output from the new PD.  With 375mW of 1064nm light incident we have 15mV of output.  Which matches well with the typical Reponsivity of 0.8V/A reported in the datasheet and our REFL11 ckt .  The schematic of the ckt is also attached here for easy reference.  The various factors are

V_dc = 0.375 mW x 0.8 V/A x 10 Ohm x 5 = 15mV

The last factor is the gain of the last stage on the DC route.

When I reassembled the box I noticed that there is problem with the SMA connectors popping out of the box.  The holes seem misplaced so I enlarged the holes to remove this concern.

I set up video monitoring of MC1 and MC3

The RGA scan is normal at day 52 of this pump down.

Light power BS 1064nm ~25mW, ETMX 532nm ~5mW

This is with reference to Kevin and Jenne's elogs  # 3890, 4034 and 4048 . 

While the electronics are working okay, there is no DC signal from the photodiode. 

Since the solderings and tracks on the PCB were fine I took a close look at the exposed front face of the photodiode.

As we can see, one of the thin wires on the top surface of the photodiode is broken.  We can see some wipe marks closer to the lower left edge..

Something seems to have brushed across the exposed face of the photodiode and dislodged the wire.

Question:

The new photodiode still has its protective can intact.   Do we need to remove the can and expose the photodiode before istallation?

The following code is incredibly useful when creating  MATLAB plots as it adds the filename of the script to the plot itself. I think it should be used for all MATLAB plots that go on the elog.

For example, I have no idea where the data/script is that was used to generate these plots.

orient landscape

xposn = 0.0;

yposn = -0.13; % you sometimes have to tweak this value depending on the page size and the number of subplots


text(xposn,yposn,[filename('fullpath'), '.m'], ...

     'Units', 'normalized', ...

     'Interpreter', 'none', ...

     'FontSize', 6)

print('-dpdf', [filename('fullpath'), '.pdf'])

[Joe,Alex]

Alex came over and we installed the new Dolphin drivers so that the front ends using the Dolphin PCIe RFM network don't pause for a long time when one of the other nodes in the network go down.  Generally this pause would cause the code to time out and quit.  Now you can take c1lsc or c1sus down without having the other have problems.

We did note on reboot however, that the Dolphin_wait script sometimes (not always) seems to hang.  Since this is run at boot up, to ensure the dolphin card has had enough to allocate memory space for data to be written/read from by the IOP process, it means nothing else in the startup script gets run if it does happen.  In this case, running "pkill dolphin_wait" may be necessary.

Note that you may still have problems if you hit the power button to force a shutdown (i.e. holding it for 4 seconds for immediate power off), but as long as you do a "reboot" or "shutdown -r now" type command, it should come down gracefully. 

What was done:

Alex grabbed the code from his server, and put it /home/controls/DIS/ on fb.

He ran the following commands in that directory to build the code.

./configure  '--with-adapter=DX' '--prefix=/opt/DIS'

make

sudo make install

He proceeded to modify the /diskless/root/etc/rc.local to have the line:

insmod /lib/modules/2.6.34.1/kernel/drivers/dis/dis_kosf.ko

In that same file he commented out

cd /root

and

exec /bin/bash/

He then modified the run levels in /diskless/root/etc/inittab. Level 0, level 3, and level 6 were changed:

l0:0:wait/etc/rc.halt

l3:3:wait:etc/rc.level3

l6:6:wait:/etc/rc.reboot

Then he created the scripts he was refering to:

rc.level3 is just:

exec /bin/bash

rc.halt is:

/opt/DIS/sbin/dxtool prepare-shutdown 0
sleep 3
halt -p

rc.reboot is:

reboot

Basically rc.halt calls a special code which prepares the Dolphin RFM card to shutdown nicely.  This is why just hitting the power button for 4 seconds will cause problems for the rest of the dolphin network.

We then checked out of svn the latest dolphin.c in  /opt/rtcds/caltech/c1/core/advLigoRTS/src/fe

The Dolphin RFM cards have a new numbering scheme.  4 is reserved for special  broadcasts to everyone, so the Dolphin node IDs now start at 8.  So we needed to change the c1lsc and c1sus Dolphin node IDs.

To change them we went to /etc/dis/dishosts.conf on the fb machine, and changed the following lines:

HOSTNAME: c1sus
ADAPTER:  c1sus_a0 4 0 4
HOSTNAME: c1lsc
ADAPTER:  c1lsc_a0 8 0 4

to

HOSTNAME: c1sus
ADAPTER:  c1sus_a0 8 0 4
HOSTNAME: c1lsc
ADAPTER:  c1lsc_a0 12 0 4

The FE models for the c1lsc and c1sus machines were recompiled and then the computers were rebooted.  After having them come back up, we tested that there was no time out by shutting down c1lsc and watching c1sus. We then reveresed and shutdown c1sus while watching c1lsc.  No problems occured.  Currently they are up and communicating fine.

The air condition was off for the south arm. I  turned it on.

 I repeated the same measurement as that Koji did before (see here) with the mixer-based frequency discriminator.

The frequency fluctuation of the beat note is now 50 kHz in rms integrated down to 0.1 Hz, which is a bit better than before.

However there still is the same undesired structure in the spectrum below 10 Hz.

Fig.1 power spectra of the green beat note fluctuation in terms of frequency fluctuation.

   Red curves were taken when the IR was locked to the MC, and the green was locked to the X arm.

Blue curves were taken when both the IR and the green were locked to the X arm.

Black curve was also the one taken when the IR and the green were locked to the X arm, but showing the lower noise level.

I have no idea what exactly was going on when I took the black curve, but this noise level sometimes showed up.

The discrepancy may come from a kind of calibration error although I kept using the same calibration factor to convert the data from count to frequency.

Need more investigations.

 Additionally Koji and I took the coherence between the beat fluctuation and the transmitted lights of both the IR and the green.

It showed a strong coherence at 1 Hz, which is one of the dominant noise of the beat note.

This probably indicates that the 1 Hz peak is produced by a coupling from amplitude fluctuation.

 For monitoring the green transmitted light, I used the Jenne's PD (see here)

Using a stray beam that is generated as the transmitted green beam from the Xarm goes through the viewport to the PSL table, I installed a fast lens (because I was constrained for space) and a Thorlabs PDA36 photodiode on the PSL table.

The BNC cable runs along the edge of the PSL table, up the corner hole with the huge bundle of cables, and over to IOO_ADC_0. It's channel 3 on the simulink model, which means that it is plugged into connector #4.

With the green resonating TEM00, I have ~1.4V output from the photodiode, as seen on a voltmeter. This corresponds to ~1500 counts on the MEDM screen.

Note to self:  Switch to a ~1cm diode with a boatload of gain (either from the 40m or Bridge), and use transmission through a steering mirror of the actual beat note path, not the jittery viewport pickoff.  Want RIN noise level to be about 1e-5, only care about below ~100Hz so don't need broadband.

[Larisa, Aidan,Steve,Suresh]

   Today was the first session for implementing the new video cabling plan laid out in the document " CCD_Cable_Upgrade_Plan_Jan11_2011.pdf"  by Joon Ho attached to his elog entry 4139.  We started to check and label all the existing cables according to the new naming scheme. 

So far we have labeled the following cables. Each has been checked by connecting it to a monitor near the Video Mux and a camera at the other end.

C1:IO VIDEO 8ETMYF

C1:IO-VIDEO 6 ITMYF

C1:IO-VIDEO 21 SRMF

C1:IO-VIDEO 25 OMCT

C1:IO-VIDEO 19 REFL

C1:IO-VIDEO 22 AS

C1:IO-VIDEO 18 IMCR

C1:IO-VIDEO 14 PMCT

C1:IO-VIDEO 12 RCT

C1:IO-VIDEO 9 ETMXF

C1:IO-VIDEO 1 MC2T

Next we need to continue and finish the labeling of existing cables.  We then choose a specific set of cables which need to be laid together and proceed to lay them after attaching suitable lables to them.

Updated the c1scx model to have two Lockin demodulators (C1:SUS-ETMX_LOCKIN1 and C1:SUS-ETMX_LOCKIN2).  There is a matrix C1:SUS-ETMX_INMUX which directs signals to the inputs of LOCKIN1 and LOCKIN2.  Currently only the GREEN_TRX signal is the only signal going in to this matrix, the other 3 are grounds.  The actual clocks themselves had to be at the top level (they don't work inside blocks) and thus named C1:SCX-ETMX_LOCKIN1_OSC and C1:SCX-ETMX_LOCKIN2_OSC.

There is a signal (IPC name is C1:GCV-SCX_GREEN_TRX) going from the c1gcv model to the c1scx model, which will contain the output from Jenne's green transmission PD which will eventually be placed. I've placed a filter bank on it in the c1gcv model as a monitor point, and it corresponds to C1:GCV-GREEN_TRX.

The suspension control screens were modified to have a screen for the Matrix feeding signals into the two lockin demodulators.  The green medm screen was also modified to have readbacks for the GREEN_TRX and GREEN_TRY channels.

So on the board, the top channel (labeled 1, corresponds to code ADC_0_0) is MCL.

Channel 2 (ADC_0_1) is assigned to frequency divided green signal.

Channel 3 (ADC_0_2) is assigned to the beat PD's DC output.

Channel 4 (ADC_0_3) is assigned to the green power transmission for the x-arm.

Channel 5 (ADC_0_4) is assigned to the green power transmission for the y-arm.

I blocked the  AP table's south west 10" ID port since it is obsolete with the new layout.

Reminder: items on the enclosure self can fall down in an earthquake. I moved oscilloscope and heavy calorimeter head from the edge of the cliff.

I did a yum-install of the latest ldg-client (to get onto the LIGO Clusters) on Rossa. 

I followed the instructions on the wiki page, and everything seemed to work nicely.

I think the new ldg client installs somewhere on the local computer, so if anyone wants cluster access on any other computer, they should follow the same directions.

[Joe, Rana]

Filter definitions for the decimation filters to epics readback channels (like _OUT16) can be found in the fm10Gen.c code (in /opt/rtcds/caltech/c1/core/advLigoRTS/src/include/drv).

At the moment, the code is broken for systems running at 32k, 64k as they look to be defaulting to the 16k filter.  I'd like to also figure out the notation and plot the actual filter used for the 16k.

Rana has suggested a 2nd order, 2db ripple low pass Cheby1 filter at 1 Hz.

  51 #if defined(SERVO16K) || defined(SERVOMIXED) || defined(SERVO32K) || defined(SERVO64K) || defined(SERVO128K) || defined(SERVO256K)
  52 static double sixteenKAvgCoeff[9] = {1.9084759e-12,
  53                                      -1.99708675982420, 0.99709029700517, 2.00000005830747, 1.00000000739582,
  54                                      -1.99878510620232, 0.99879373895648, 1.99999994169253, 0.99999999260419};
  55 #endif
  56
  57 #if defined(SERVO2K) || defined(SERVOMIXED) || defined(SERVO4K)
  58 static double twoKAvgCoeff[9] = {7.705446e-9,
  59                                  -1.97673337437048, 0.97695747524900,  2.00000006227141,  1.00000000659235,
  60                                  -1.98984125831661,  0.99039139954634,  1.99999993772859,  0.99999999340765};
  61 #endif
  62
  63 #ifdef SERVO16K
  64 #define avgCoeff sixteenKAvgCoeff
  65 #elif defined(SERVO32K) || defined(SERVO64K) || defined(SERVO128K) || defined(SERVO256K)
  66 #define avgCoeff sixteenKAvgCoeff
  67 #elif defined(SERVO2K)
  68 #define avgCoeff twoKAvgCoeff
  69 #elif defined(SERVO4K)
  70 #define avgCoeff twoKAvgCoeff
  71 #elif defined(SERVOMIXED)
  72 #define filterModule(a,b,c,d) filterModuleRate(a,b,c,d,16384)
  73 #elif defined(SERVO5HZ)
  74 #else
  75 #error need to define 2k or 16k or mixed
  76 #endif

 Yesterday I moved the whole green electronics stuff, which had been sitting on the floor at the X end,  into a new electronics rack.

The rack now is placed under the cable rail close to the ETMX chamber.

 I did a quick back of the envelope calculation of the expected green phase change on reflection from the aLIGO ITM.

The phase change per nm, K1 = delta phi/delta Lambda, around 532nm is ~1.5 degrees/nm (from the LMA data) [this number is approximately 100x smaller at 1064nm]

I assumed that very small changes in the thickness of the coating appear equivalent to shifting the spectra for reflection/transmission/phase-change-on-reflection up or down by delta lambda, where

delta Lambda/Lambda = delta h/h

where h is the total thickness of the coating and delta h is the change in the thickness of the coating.

Assume that delta h/h = alpha deltaT, where alpha is the coefficient of thermal expansion and delta T is the change in temperature. (approximately 1K)

Then delta phi = K1* Lambda * alpha * delta T = 1.5 degrees/nm * 532nm * 10^-5 K^-1 * 1.0 K =  8 * 10^-3 degrees.

Assume that 360 degree phase change corresponds to one FSR.

Therefore, the frequency shift due to temperature change in the coating = 8*10^-3/360 * FSR = 2.2 *10^-5 * FSR.

Therefore, the expected frequency shift per degree temperature change = 2.2*10^-5 * FSR [Hz/K]

Here's the reference for the self-reference frequency detection idea. See Figure 2.

http://www.phys.hawaii.edu/~anita/new/papers/militaryHandbook/mixers.pdf

I noticed that the RMTEMP channel was spiking myteriously when Kiwamu opened the PSL door. We found out that the LEMO connectors would intermittently short to the case and cause ~1 deg steps in the temeprature.

We have removed the case and examined it. Not only were the connections to the box intermittent, there was a cold solder joint inside on an unsecured flying add-on opamp. The whole thing is a giant hack.

PK was the last person to work on this box, but I'm sure that he wouldn't have left it in this state. Must be gremlins.

The LEMO connectors on the front are the ones touching. The LT1021 is the badly soldered part.

The backup appears to have finished on nodus, and I've put the rsync job back in the crontab.

I swapped over to a 3x longer cable (old 65 ft. Pasternak cable from ancient 40m days). The old one was 6m, the new one is 18.2 m. It was already coiled up so I put it into a tupperware box to shield it somewhat from the HVAC wind.

The noise went down nearly proportional to the length (after I recalibrated the DAQ channel for the ~3x higher phase->voltage gain). With this length, the peak-peak mixer range is 5.5 MHz, so still enough to go an FSR here.

I give credit to the low frequency improvement entirely to Tupperware for their excellent containers. The current noise limit is most likely the SR560.

This diagram shows the setup of the analog Mixer-Frequency Discriminator (MFD).

The idea is similar to the one of the Schnupp Asymmetry for our Michelson interferometers. The signal from the PD (or any signal source for which you want to know the frequency) is split into two legs; one leg is much longer than the other. The two legs are recombined at a mixer/demodulator. The demodulator output varies sinusoidally with the phase difference of two legs, the same as when we try to measure the phase noise of an oscillator, for example. This is the same concept as the digital frequency discriminator that Aidan and Joe put into the GFD FE system recently.

With a ~1m cable length asymmetry, we get 180 deg of phase shift for a ~100 MHz signal (recall that the speed of light in most of our cables is ~2 x 10^8 m/s). The mixer gives a linear output at 50 MHz (and 150 MHz, 250 MHz, etc.).

This single mixer based setup is fine for most everything we do. In order to get even more resolution, one can just use 2 mixers by splitting the signal with a 4-way instead of 2-way mixer. One setup can have a 0.5-1 m asymmetry to have a large range. The other can have a ~10-30m asymmetry to get a comb of linear readouts.

Typically, we will have some kind of weak signal at the photodiode and will use a 20 or 40 dB gain RF amp to get the signal into the mixer. In this case, the mixer output noise will be at the level of tens of nV/rHz. Any usual low noise audio amplifier (SR560 variety) will be enough to read out the signal.

Why the 50 Ohm terminator? If you look at the specs of the BLP-1.9 filter from Mini-Circuits (its the same for almost all of their LP filters) you see that there's ~90 dB of attenuation above ~30 MHz (where our signals 2*f product will show up). If we use an RF input signal of ~0 dBm, this means that we get a high frequency product of -95 dBm (~10 uVrms) which is OK. But the return loss is 0 dB above 5 MHz - this means that all of the high frequency content is reflected back into the mixer! The 50 Ohm terminator is there to absorb the RF signals coming out of the mixer so as to prevent them from going back into the mixer and mixing with the RF/LO signals. The 50 Ohm terminator does attenuate the DC/audio frequency signals we get out of the mixer by a factor of two, but that's OK since we are not limited by the mixer's thermal noise.

Noise Measurement:

To checkout the noise, we used a 6m RG-58 cable in one leg. We used the DS345 signal generator for the source. We adjusted the frequency to (~21 MHz) give a ~zero mean signal at the demod output. The 6m cable makes the demod output's peak-peak swing correspond to ~16 MHz. We then used an SR560, DC coupled, G=1000, low-noise, 2pole low pass at 1 kHz, to get the signal into the ADC.

The attached plot shows the noise. We have caibrated the digital gain in the channel to make the output into units of Hz. The high frequency noise floor is ~0.3 Hz/rHz and the 1/f knee is at 10 Hz. This setup is already good enough for all of the green locking work at the 40m. In order to make this useful for the reference cavity work or the gyro, we will have to use a longer cable and a lower noise audio amplifier.

As can be seen from the plot, the ADC noise is below the measured noise. The noise of the SR560 with the input terminated is shown in grey - the measured noise of the MFD is very close to this. In order to improve the performance, the next step should be to use a longer cable. There's clearly going to be some trade-off between the temperature dependent effects which come with long cables (dphi/dT gets bigger) and trying to use a high gain ~1 nV/rHz amplfier at the mixer output.

Temperature Drift of the long cable:

This 24-hour minute-trend shows the frequency wander as well as the room temperature. This is not proof of a temperature dependence, but if it is then we get ~3 kHz/deg for the sensitivity. If this is actually the cable and not the amplifier, then we'll have to hunt for a lower tempco cable and put it in a box to isolate it.

We set up the mixer based FD to check out its noise performance.

It is being acquired as C1:GCV-XARM_FINE_OUT_DAQ.

We have calibrated it by driving the frequency of the RF signal generator and putting the value into the GAIN field. We got 100 kHz / 5450 counts; the _OUT_DAQ channel is now being recorded in units of Hz. The cable length has been adjusted so that the full mixer output can swing 16 MHz peak-peak before turning over.

Also, we did a lot of cable cleanup around the IO rack. Kiwamu and Suresh's setups were somewhat dismantled. The whole area was too messy and too hacky to be allowed to survive. Our "temporary" setups have a way of becoming permanent holding places for barrels, adapters, duct tape, etc.

Removed some lines from the PATH environment variable since they point to old codes which no longer work with the new frame builder and setup.

The change was:

#setenv PATH $LINUXPATH/bin:$GDSPATH/bin:$ROOTSYS/bin:$TDSPATH/bin:${SCRIPTPATH}:$PATH
setenv PATH $TDSPATH/bin:${SCRIPTPATH}:$PATH


<p>I removed the rsync backup from nodus' crontab temporarily so as to not have multiple backup jobs running.&nbsp; The job I started from yesterday was still running.&nbsp; Hopefully the backup will finish by Monday.</p>
<p>The line I removed was:</p>
<p>0 5 * * * /opt/rtcds/caltech/c1/scripts/backup/rsync.backup</p>
<table align="left" width="786" cellspacing="1" cellpadding="1" border="2">
    <tbody>
        <tr>
            <td><span style="font-size: larger;">MC damp</span></td>
            <td><span style="font-size: larger;">dataviewer</span></td>
            <td><span style="font-size: larger;">diaggui</span></td>
            <td><span style="font-size: larger;">AWG</span></td>
            <td><span style="font-size: larger;">c1lsc</span></td>
            <td><span style="font-size: larger;">c1ioo</span></td>
            <td><span style="font-size: larger;">c1sus</span></td>
            <td><span style="font-size: larger;">c1iscex</span></td>
            <td><span style="font-size: larger;">c1iscex</span></td>
            <td><span style="font-size: larger;">RFM</span></td>
            <td><span style="">The Dolphins</span></td>
            <td><span style="font-size: larger;">Sim.Plant</span></td>
            <td><span style="font-size: larger;">Frame builder</span></td>
            <td><span style="font-size: larger;">TDS</span></td>
            <td><span style="font-size: larger;">Cabling</span></td>
        </tr>
        <tr>
            <td bgcolor="blue"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="green"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="blue"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="yellow"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="orange"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="yellow"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="blue"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="yellow"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="yellow"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="blue"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="blue"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="red"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="blue"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="orange"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="orange"><span style="font-size: larger;">&nbsp;</span></td>
        </tr>
    </tbody>
</table>

All start and kill scripts for the front end models have been moved into the FE directory under scripts:  /opt/rtcds/caltech/c1/scripts/FE/.  I modified the Makefile in /opt/rtcds/caltech/c1/core/advLigoRTS/ to update and place new scripts in that directory. 

This was done by using

sed -i 's[scripts/start$${system}[scripts/FE/start$${system}[g' Makefile

sed -i 's[scripts/kill$${system}[scripts/FE/kill$${system}[g' Makefile

This measurement pertains to the BL2002 VCO PLL unit.

Our goal is to measure the frequency fluctuations introduced by the VCO. 

First the VCO calibration was checked.  It is -1.75 MHz per volt.  The calibration data is below:

Next we measured the Transfer function between points A and B  in the diagram below using the Stanford Research System's SR785.  This measurement was done with loop opened just after the 1.9MHz LPF and with the loop closed.

The TF[open] / TF [closed ] gave the total gain in the loop.  As shown below:

Green curve is the Transfer Function with the loop open and the red with that of the loop closed.

Gain Shown below is the quotient TF[open]/TF[closed]

 c) As can be seen from the graph above the loop gain is >>1 over 0.1 to 300Hz.  And hence the frequency noise of the VCO is just the product of the voltage noise and the VCO calibration factor over this range,

d) the noise power at the point B was measured and multiplied by the VCO calibration  factor to yield dF(rms)/rtHz:

The green line with dots are the data

The blue line is the rms frequency fluctuation.

This corresponds to a arm length fluctuation of about 20pm.

So today, after an "rm" error while working with the autoburt.pl script and burt restores in general, I asked Dan Kozak how to actually look at the backup data.  He said there's no way to actually look at it at the moment.  You can reverse the rsync command or ask him to grab the data/file if you know what you want.  However, in the course of this, we realized there was no /cvs/cds data backup.

Turns out, the rsync command line in the script had a "-n" option.  This means do a dry run.  Everything *but* the actual final copying.

I have removed the -n from the script and started it on nodus, so we're backing up as of 5:22pm today.

I'm thinking we should have a better way of viewing the backup data, so I may ask Dan and Stewart about a better setup where we can login and actually look at the backed up files.

In addition, tomorrow I'm planning to add cron jobs which will put changes to files in the /chans and /scripts directories into the SVN on a daily basis, since the backup procedure doesn't really provide a history for those, just a 1 day back backup.

Updated the FILTER.adl file to have the yellow button moved up, and replaced the symbol in the upper right with a white A with black background.  I made a backup of the filter file called FILTER_BAK.adl.  These are located in /opt/rtcds/caltech/c1/core/advLigoRTS/src/epics/util.

I also modified the Makefile in /opt/rtcds/caltech/c1/core/advLigoRTS/ to make the startc1SYS scripts it makes take in an argument.  If you type in:

sudo startc1SYS 1

it automatically writes 1 to the BURT RESTORE channel so you don't have to open the GDS_TP screen and by hand put a 1 in the box before the model times out.

The scripts also points to the correct burtwb and burtrb files so it should stop complaining about not finding them when running the scripts, and actually puts a time stamped burt snapshot in the /tmp directory when the kill or start scripts are run.  The Makefile was also backed up to Makefile_bak.

Joe and I were looking at the RCG VCO algorithm to determine if we could adapt it to run at a faster rate (you can currently change its frequency at 1Hz). I noticed that the algorithm that is used to calculated the values of sine and cosine at time T1  is a truncated Taylor series which uses the values of sine and cosine calculated at time T1 - Delta t . I was concerned that there would be an accumulating phase error so I tested the algorithm in MATLAB and compared it to a proper calculation of sine and cosine. It turns out that at a given 'requested' frequency there is a constantly accumulating phase error - which means that the 'actual' frequency of the RCG VCO is incorrect. So I have plotted the frequency error vs requested VCO frequency. It gets pretty bad!

 Here's the code I used:

dt = 1/16384;

diffList = [];
% set the frequencies
flist = 1:5:8192;
for f = flist;
   
    % get the 'accurate' values of sine and cosine
    tmax = 0.05;
    time1 = dt:dt:tmax;
    sineT = sin(2.0*pi*f*time1);
    cosineT = cos(2.0*pi*f*time1);
   
    % determine the phase change per cycle
    dphi = f*dt*2*pi;
    cosT1 = 1:numel(time1);
    sinT1 = 0*(1:numel(time1));
   
    % use the RCG VCO algorithm to determine the values of sine and cosine
    for ii = 1:numel(time1) - 1;                 
        cosNew = cosT1(ii)*(1 - 0.5*dphi^2) ...
                      - (dphi)*sinT1(ii);
        sinNew = sinT1(ii)*(1 - 0.5*dphi^2) ...
                      + (dphi)*cosT1(ii);
                 
       
        cosT1(ii+1) = [ cosNew];
        sinT1(ii+1) = [ sinNew];
       
    end
    % extract the phase from the VCO values of sine and cosine
    phaseT = unwrap(angle(cosineT + i* sineT));
    phaseT1 = unwrap(angle((cosT1 + i*sinT1)));
   
    % determine the phase error for 1 cycle
    diff = phaseT1 - phaseT;
    % determine the frequency error
    slope = (diff(2) - diff(1))/(dt);
   
    diffList = [diffList, slope];
    disp(f)
    pause(0.001)
end

% plot the results
close all
figure
orient landscape
loglog(flist, abs(diffList/(2.0*pi)))
xlabel('Requested VCO Frequency (Hz)')
ylabel('Frequency error (Hz)')
grid on

print('-dpdf', '/users/abrooks/VCO_error.pdf')


I wonder why POY11 has the dark noise level of 90nV/rtHz that is 5 times larger than that of POX (18nV/rtHz)
even though the Q are the same (~15) and the transimpedance is better (3.9k instead of 2k).

What cause this high noise level?
What is the expected dark noise level?

[Suresh, Joe]

We added the following two new DAQ channels into the c1:GCV model.  The daq:analog input channels are on card ADC0 and correspond to channels 3 and 4 on the card.

c1:GCV-EXT_REF_OUT_DAQ   Sampling rate=2kHz  acquiring a 1Hz sine wave from the SRS Function Generator DS345.  This is using the Rb 10MHz signal as an external frequency reference.

c1:GCV-PLL_OUT_DAQ    Sa.rate=2kHz acquiring the demodulated signal from the PLL servo.

This work is connected to the study of VCO PLL loop noise at frequencies below 0.1Hz.    We are trying to measure phase noise in the VCO PLL servo at low frequencies as this noise would result in arm length fluctuations in the green-locking scheme.

[Koji and Kevin]

I measured the shot noise of POY and fit the data to determine the RF transimpedance at 11 MHz and the dark current. The transimpedance is (3.860 +- 0.006) kΩ. I realize that there are not many data points past the dark current but I did not want to take any further data because the light bulb was getting pretty bright. If this is a problem, I can try to redo the measurement using a lens to try to focus more of the light from the bulb onto the photodiode.

I also measured the spectrum and recorded a time series of the RF signal with the light to the photodiode blocked. These measurements do not show any large oscillations like the ones found for POX.

The plots of the measurements are on the wiki at http://lhocds.ligo-wa.caltech.edu:8000/40m/Electronics/POY.

[Joe, Jenne]

We modified the activateDAQ.py script to handle the C1PEM.ini file (defining the PEM channels being recorded by the frame builder) in addition to all the optics channels.  Jenne will be modifying it further so as to rename more channels.