40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 176 of 339  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  877   Mon Aug 25 11:43:55 2008 YoichiFrogsIOOMC REFL PD cable had been disconnected through out the weekend
Most of my morning was wasted by the MC REFL PD cable, which was disconnected on the generic LSC PD interface board.
I know who did this. *ME*. When I pulled out the MC board, which is sitting next to the PD interface, on Friday, I must have
disconnected the PD cable accidentally. The connector of the PD cable (D-Sub) does not have screws to tighten and easily comes off.
I wrote this entry to warn other people of this potential problem.
  889   Tue Aug 26 19:07:37 2008 YoichiHowToComputersReading data from Agilent 4395A analyzer through GPIB from *Linux* machine
I succeeded in reading data from Agilent 4395A analyzer, who's floppy is crappy, through GPIB from a Linux machine using
agilent 82357B USB-GPIB interface.
I installed the linux GPIB driver to one of the lab. laptops (the silver DELL one currently sitting on the 4395A analyzer).
I wrote an initialization script for the USB-GPIB interface and a small python script for reading data from the analyzer.

[Usage]

1. Connect the USB-GPIB interface to the laptop and the analyzer.
2. Run /usr/local/bin/initGPIB command (it takes about 10sec to complete).
3. Run /usr/local/bin/getgpibdata.py > data.txt to save data from the analyzer to a text file.

The data format is explained in the comments of getgpibdata.py
This method is way faster than the unreliable floppy. The data is transfered in a few sec.

I'm now writing a wiki page on this
http://lhocds.ligo-wa.caltech.edu:8000/40m/GPIB

I will install the same thing into the other DELL laptop soon.
Let me know if you have trouble with this.
  890   Wed Aug 27 10:55:35 2008 YoichiHowToComputersAnnoying behavior of the touch pads of the lab. laptops is fixed
I was sick of the stupid touch pad behavior of the lab. laptops, i.e. firefox goes back and forth in the history when the cursor is moved.
It was caused by firefox mis-interpreting the horizontal scroll signal as back/forward command.
I stopped it by going to about:config in firefox and set mousewheel.horizscroll.withnokey.action to 0 and
mousewheel.horizscroll.withnokey.sysnumlines to true.
  896   Fri Aug 29 10:20:32 2008 YoichiConfigurationPSLbeam block distorted

Quote:
There was a beam block after the Mach Zender. Who or what put this there?

The going to the MC now looks distorted as if someone has left something funny in the beam or maybe the new PMC has started to degrade??

Use the ELOG people...its good for you.


I put the block. I was frequently reaching to the FSS box to change the test point probes. I put the block to protect my hands/clothes from being burnt accidentally.
  902   Fri Aug 29 16:35:18 2008 YoichiConfigurationPSLbeam block distorted

Quote:
There was a beam block after the Mach Zender. Who or what put this there?

The going to the MC now looks distorted as if someone has left something funny in the beam or maybe the new PMC has started to degrade??

Use the ELOG people...its good for you.


The apparent distortion of the MC refl. was caused by mis-alignment of the MC mirrors.
Because the MC1 was mis-aligned, the reflected light was clipped by a steering mirror.
I restored the MC angle bias values from the conlog history and now the MC locks.
According to conlog, the MC alignment was changed at around 18:30 on Thursday PDT.
It could have been caused by the computer reboots.
  905   Fri Aug 29 22:57:48 2008 YoichiUpdatePSLFSS loop transfer functions
I've been measuring a bunch of transfer functions of the FSS related stuffs.
There are a lot to be analyzed yet, but here I put one mystery I'm having now.
Maybe I'm missing something stupid, so your suggestions are welcome.

Here is a conceptual diagram of the FSS control board

                                                          TP3             TP4
                                                           ^               ^
                                                           |               |
RF PD -->--[Mixer]-----[Sum Amp]------>--[Common Gain]--->----[Fast Gain]----[Filter]--> NPRO PZT
              ^     |      ^        |                  |     
              |     V      |        V                  |
LO ---->-------    TP1     IN      TP2                 -->---[Filter]--[High Volt. Amp.] --> Phase Corrector

What I did was first to measure a "normal" openloop transfer function of the FSS servo.
The FSS was operated in the normal gain settings, and a signal was injected from "IN" port.
The open loop gain was measured by TP1/TP2.
Now, I disconnected the BNC cable going to the phase corrector to disable the PC path and locked the ref. cav. 
only using the PZT. This was done by reducing the "Common Gain" and "Fast Gain" by some 80dB.
Then I measured the open loop gain of this configuration. The UGF in this case was about 10kHz.
I also measured the gain difference between the "normal" and "PZT only" configurations by injecting 
a signal from "IN" and measuring TP3/TP2 and TP4/TP3 with both configurations (The signal from the Mixer was
disconnected in this measurement). 

The first attachment shows the normal open loop gain (purple) and the PZT only open loop gain scaled by the 
gain difference (about 80dB). The scaled PZT open loop gain should represent the open loop gain of the PZT
path in the normal configuration. So I expected that, at low frequencies, the scaled PZT loop TF overlaps the normal
open loop TF.
However, it is actually much larger than the normal open loop gain.
When I scale the PZT only TF by -30dB, it looks like the attachment #2.
The PZT loop gain and the total open loop gain match nicely between 20kHz and 70kHz.
Closer look will show you that small structures (e.g. around 30kHz and 200kHz) of the two
TFs also overlap very well. I repeated measurements many times and those small structures are always there (the phase is
also consistently the same). So these are not random noise.

I don't know where this 30dB discrepancy comes from. Is it the PC path eating the PZT gain ?

I have measured many other TFs. I'm analyzing these.
Here is the TO DO list:

* Cavity response plot from AOM excitation measurements.
* Cavity optical gain plot.
* Reconstruct the open loop gain from the electric gain measurements and the optical gain above.
* Using a mixer and SR560(s), make a separate feedback circuit for the PZT lock. Then use the PC path
  to measure the PC path response.
* See the response of the FSS board to large impulse/step inputs to find the cause of the PC path craziness.
etc ...
Attachment 1: OPLTFs.pdf
OPLTFs.pdf
Attachment 2: OPLTFsScaled.pdf
OPLTFsScaled.pdf
  908   Mon Sep 1 19:23:17 2008 YoichiConfigurationPSLFSS on an auxiliary loop
Summary: The FSS is now temporarily disabled. Naturally, the MC won't lock. I will fix it tomorrow morning.

Today, I did the 4th item of my TO DO list.
Using a mini-circuit mixer and two SR560s, I constructed an auxiliary servo loop for the reference cavity.
With this loop, I was able to lock the reference cavity without using the FSS box.
By locking the reference cavity with this auxiliary servo, I was able to measure the PC path transfer function.
I will post the analyzed results later.

I borrowed the PD RF and the LO signals from the main FSS loop by power splitters. Therefore, the gain of the main FSS loop
is now about 3dB low. I tried to compensate it by increasing the EOM modulation depth, but the PC path is still a bit noisy.
Probably the already too low LO power is now seriously low (the LO power cannot be changed from EPICS).
Because I did not want to leave the PC path with large output overnight (it will heat up the PA85, and might cause damage, though unlikely),
I disabled the FSS for now.
  910   Tue Sep 2 09:58:42 2008 YoichiConfigurationPSLFSS on an auxiliary loop

Quote:
Summary: The FSS is now temporarily disabled. Naturally, the MC won't lock. I will fix it tomorrow morning.


Now I removed the power splitters for the aux. reference cavity servo. The FSS is back and the MC locks.
I'm now returning one of the active high-impedance probes to the Wilson house. They need it today.
We are left with only one active probe. If anyone finds another active probe in the 40m lab.,
please let me know (according to Rana we should have one more).
  912   Tue Sep 2 14:28:41 2008 YoichiUpdatePSLFSS EOM driving signal spectra
Rich advised me to change the +10V input of the FSS crystal frequency reference board from whatever voltage supply we use now to a nice one.
This voltage is directory connected to the signal lines of both LO and RF output amps. Therefore, fluctuations in the voltage directly appear
in the outputs, though DC components are cut off by the AC coupling capacitors.

I changed the source of this voltage from the existing Sorensen one to a power supply sitting next to the rack.
The attached plots shows the difference of the RF output spectra between the two 10V sources.
The low frequency crap is almost gone in the new 10V spectrum.

I tried to increase the FSS gain with the new 10V, but still it goes crazy. I suspect it is because the LO power is too low.
Attachment 1: RFDrive1.png
RFDrive1.png
Attachment 2: RFDrive2.png
RFDrive2.png
  913   Tue Sep 2 22:43:16 2008 YoichiConfigurationPSLUpdated FSS open loop TF
Since the LO level of the FSS servo was too low, I replaced the RF oscillator board with a combination of
a Stanford signal generator and an RF amplifier.
Right now, the POY RF amplifier is used for this purpose temporarily.
Now the LO level is about 16dBm. The RF power going into the EOM is attenuated by 20dB from the LO level.
I played with the cable length to get the phase right.
Then I was able to lock the FSS with the new RF signal source.

Attached is the open loop transfer function of the current FSS. Now the UGF is a bit above 200kHz, a factor of 2 improvement.
This gain was achieved with the common gain slider at 13.5dB and the fast gain = 30dB.
With the old RF oscillator board, UGF=100kHz was achieved with the common gain =30dB. Therefore, the increase of the LO gave
us a large signal gain.

Increasing the gain further, again ,makes the PC path crazy.
Rich suggested that this craziness was caused either by the slew rate limit of the PA85 or the output voltage limit of the bypass Op-amp(A829)
is hit.

TO DO:
* Look at the error signal spectrum to see if there is any signal causing the slew rate saturation at high frequencies.
* Find out what the RF signal level for the EOM should be. 20dB attenuation is an arbitrary choice.
* Find out the cross over frequency. Determine where the fast gain slider should be.
etc ...
Attachment 1: OPLTF.png
OPLTF.png
  915   Wed Sep 3 18:43:19 2008 YoichiConfigurationElectronicsTwo more active probes
I found two active probes, an HP41800A and a Tektronix P6201.
Thanks John for telling me you saw them before.
Now we have three active probes, wow !
We have to find or make a power supply for P6201.
The manual of the probe is attached.
Attachment 1: Tektronix-P6201-active-probe.pdf
Tektronix-P6201-active-probe.pdf Tektronix-P6201-active-probe.pdf Tektronix-P6201-active-probe.pdf Tektronix-P6201-active-probe.pdf Tektronix-P6201-active-probe.pdf Tektronix-P6201-active-probe.pdf Tektronix-P6201-active-probe.pdf Tektronix-P6201-active-probe.pdf
  917   Wed Sep 3 19:09:56 2008 YoichiDAQComputersc1iovme power cycled
When I tried to measure the sideband power of the FSS using the scan of the reference cavity, I noticed that the RC trans. PD signal was not
properly recorded by the frame builder.
Joe restarted c1iovme software wise. The medm screen said c1iovme is running fine, and actually some values were recorded by the FB.
Nonetheless, I couldn't see flashes of the RC when I scanned the laser frequency.
I ended up power cycling the c1iovme and run the restart script again. Now the signals recorded by c1iovme look fine.
Probably, the DAQ boards were not properly initialized only by the software reset.
I will re-try the sideband measurement tomorrow morning.
  919   Thu Sep 4 07:29:52 2008 YoichiUpdatePSLc1iovme power cycled

Quote:
Entry 663 has a plot of this using the PSL/FSS/SLOWscan script. It shows that the SB's were ~8x smaller than the carrier.
P_carrier   J_0(Gamma)^2 
--------- = ------------
P_SB        J_1(Gamma)^2

Which I guess we have to solve numerically for large Gamma?


P_carrier/P_SB = 8 yields gamma=0.67.
  920   Thu Sep 4 07:46:10 2008 YoichiUpdateIOOMC is now happy
The MC has been locked for more than 12 hours continuously now !
Changes I made yesterday were:
(1) Removed the 20dB attenuator before the EOM.
(2) Reduced the Fast Gain from 21dB to 16dB, which made the PC to be a little bit more loaded (~0.6Vrms).

As Rana pointed out in the meeting, setting the Fast Gain a bit lower may have put the FSS in a stabler state.
Attachment 1: MC-lock.png
MC-lock.png
  923   Thu Sep 4 13:48:50 2008 YoichiUpdatePSLFSS modulation depth
I scanned the reference cavity with the NPRO temperature (see the attached plot).
The power ratio between the carrier and the sideband resonances is about 26.8.
It corresponds to gamma=0.38.
The RF power fed into the EOM is now 14.75dBm (i.e. 1.7V amplitude). The NewFocus catalog says 0.1-0.3rad/V. So
gamma=0.38 is a reasonable number.




Attachment 1: RCScan.png
RCScan.png
  926   Thu Sep 4 17:03:25 2008 YoichiUpdatePSLRF oscillator noise comparison
I measured current spectra of the RF signal going to the FSS EOM.
The attachment compares the spectra between a Stanford signal generator and a Marconi.
I borrowed the Marconi from the abs. length measurement experiment temporarily.
The measurement was done using the signal going to the EOM. That means the spectra include
noise contributions from the RF amp., splitter and cables.

21.5MHz peak was not included because that would overload the ADC and I would have to use a large attenuation.
This means the measurement would be totally limited by ADC noise everywhere except for 21.5MHz.

I noticed that with the Marconi, the FSS is a little bit happier, i.e. the PC path is less loaded
(0.9Vrms with Stanford vs. 0.7Vrms with Marconi). But the difference is small.
Probably the contribution from the 77kHz harmonics in the laser light is more significant (see entry #929).
Also the peaks in the Stanford spectrum are not harmonics of 77kHz, which we see in the FSS error signal.

I returned the Marconi after the measurement to let Alberto work on the abs. length measurement.
Attachment 1: RFSpectra.png
RFSpectra.png
  927   Thu Sep 4 17:12:57 2008 YoichiUpdatePSLFSS open loop TF
I changed the gain settings of the FSS servo.
Now the Common Gain is 5dB (the last night it was 2dB) and the Fast Gain is 12dB (formerly 16dB).
I measured the open loop TF with this setting (the attachment).
I also plotted the OPLTF when CG=2dB, FG=20.5dB. With this setting, the MC looses lock every 30min.

You can see that the OPLTF is smoother with FG=12dB.
When the FG is high, you can see some structure around 250kHz. This structure is reproducible.
This may be some interruption from the fast path to the PC path through a spurious coupling.
Attachment 1: FSS-OPLTFs.png
FSS-OPLTFs.png
  928   Thu Sep 4 17:17:03 2008 YoichiUpdateIOOMC open loop TF
I measured open loop transfer functions of the MC servo.
The UGF was about 30kHz. Since there was some gain margin at higher frequencies, I increased
the input gain of the MC servo board from 19dB to 22dB. Now the UGF is 40kHz and we have more
phase margin (~30deg).
Attachment 1: MC-OPLTF.png
MC-OPLTF.png
  929   Thu Sep 4 17:44:27 2008 YoichiUpdatePSLFSS error signal spectrum
Attached is a spectrum of the FSS error signal.
There are a lot of sharp peaks above 100kHz (the UGF of the servo is about 200kHz).
These are mostly harmonics of 77kHz. They are the current suspects of the FSS slew rate saturation.
I remember when I blocked the light to the PD, these peak went away. So these noises must be
in the light. But I checked it a few weeks ago. So I will re-check it later.

One possible source of the lines is a DC-DC converter in the NPRO near the crystal.
We will try to move the converter outside of the box.
Attachment 1: FSS-Error-Spe.png
FSS-Error-Spe.png
  937   Mon Sep 8 15:38:57 2008 YoichiConfigurationPSLPOY RF amp is back to its original task
I temporarily fixed the busted ZHL-32A RF amplifier's power connector by simply soldering a cable to the internal circuit and pulling the cable out of the box through a hole for the power connector.
So I released the POY RF amplifier from the temporary duty of serving the FSS RF distribution and put it back to the original task,
so that Rob can finally re-start working on the lock acquisition.
Now the temporarily fixed ZHL-32A is sitting next to the IOO rack along with the power supply and a Stanford signal generator.
Please be careful not to topple over the setup when you work around there. They will be there until Peter's Wentzel RF box arrives.
  939   Wed Sep 10 13:28:25 2008 YoichiSummaryElectronicsIOO rack lost -24V (recovered)
Alberto, Yoichi

This morning, the MC suddenly started to be unwilling to lock.
I found a large offset in the MC servo board.
It turned out that -24V was not supplied to the Eurocard crate of the IOO rack.
We found two loose cables (violet, that means -24V) around the cross connects with fuses.
We connected them back, and the -24V was back.
The MC locks fine now, and Alberto can continue his arm length experiment.
  949   Tue Sep 16 10:57:45 2008 YoichiConfigurationPEMParticle counter gain
Summary:
Since we reduced the integration time of the particle counter by a factor of 10, we had to add a gain of 10
to the EPICS channels C1:PEM-count_full and C1:PEM-count_half.
I asked Alex to change it and he did it. I forgot to ask him to change the gain of C1:PEM-count_half. So now only
C1:PEM-count_full has x10 gain.

Detail:
C1:PEM-count_full and C1:PEM-count_half are 'Soft Channel' records in the database (Pcount.db). The values are actually
written into the VAL fields directly by an SNL code Particle.o.
Particle.o reads data from the RS-232C port, to which the particle counter is connected. Then it parses the data and put values
into relevant EPICS channels using channel access. This means we cannot change the gain of the channels by modifying the
database file. For example, ASLO field does not have any effect when the value is directly written into the VAL field.
We had to modify the SNL code. Alex modified Particle.st and the new SNL object file is Particle_x10.o sitting in 
/cvs/cds/caltech/target/c1psl/. I modified seq.load so that c1psl loads Particle_x10.o when rebooted.
The source code for the old Particle.st can be found on lesath.ligo.caltech.edu in
/export/CDS/d/epics/apple/Caltech/40mVac/40mVacScipe/dev/src
I asked Alex to disclose the location of the source of the new code.
In order to compile the SNL code into an object file for Motorola CPU by ourselves, we have to call Dave Barker at LHO.
  950   Tue Sep 16 13:04:22 2008 YoichiConfigurationPEMC1:PSL-FSS_RMTEMP alarm level changed
At the request of Steve, I modified the HIGH value of C1:PSL-FSS_RMTEMP from 21.27 to 23.0.
The HIHI is set to 23.50.
  954   Wed Sep 17 13:43:54 2008 YoichiConfigurationPSLRC sweep going on
I'm doing a cavity sweep of the RC. Please leave the IFO untouched until the meeting is over.
  957   Wed Sep 17 15:22:31 2008 YoichiConfigurationPSLRC sweep going on

Quote:
I'm doing a cavity sweep of the RC. Please leave the IFO untouched until the meeting is over.


The measurement is still going on.
I will post an entry when it is done.
Thank you for the patience.
  958   Wed Sep 17 17:31:24 2008 YoichiUpdatePSLFSS calibration
I calibrated the reference cavity error signal with the following procedure.

(1) I disconnected the PC path BNC cable and locked the RC only using the PZT. To do so, I had to insert a 20dB attenuator
in the RF signal path going to the EOM to reduce the gain of the loop sufficiently.
The normal RF level going to the EOM is 17dBm. With the attenuator it is of course -3dBm.

(2) Using the SR785, I injected signal into the Test-IN2 (a sum-amp after the mixer) of the FSS box and measured the TF from the Ramp-IN to the IN1.
When the Ramp-In switch is off, the Ramp-IN port can be used as a test point connected to the PZT drive signal path just before the output.
There is a RC low-pass filter after the Ramp-IN. IN1 is the direct output from the mixer (before the sum-amp).
The attm1 is the measured transfer function along with the fitting by a first order LPF.
From this measurement, the DC transfer function from the applied voltage on the PZT to the error signal is determined to be 163.6 (V/V).
Since the RF level is lowered by 20dB, the cavity gain in the normal operation mode is 10 times larger (assuming that the modulation depth is
linearly proportional to the applied voltage to the EOM).

(3) According to elog:791, the conversion factor from the voltage on the PZT to the frequency change of the NPRO is 11.172MHz/V. Combining this with the
number obtained above, we get 6.83kHz/V as the calibration factor for converting the error signal (mixer output) to the frequency at DC.
Using 38kHz cavity pole frequency, the calibration factor is plotted as a function of frequency in the attm2.

(4) I took a spectrum of the error signal of the FSS and calibrated it with the obtained calibration factor. See attm3.
The spectrum was measured by SR785. I will measure wide band spectra with an RF analyzer later.

TO DO:
1: Use the actual modulation depth difference to extrapolate the calibration factor obtained by with a low RF signal for the EOM.
The cavity sweep was already done.

2: I assumed 38kHz cavity pole. I will measure the actual cavity pole frequency by cavity ringdown.

3: Measure out-of-the-loop spectrum of the frequency noise using PMC and MC.
Attachment 1: PZTresp.png
PZTresp.png
Attachment 2: Calibration.png
Calibration.png
Attachment 3: FreqNoiseSpectrum.png
FreqNoiseSpectrum.png
  959   Wed Sep 17 17:58:35 2008 YoichiConfigurationPSLRC sweep going on
The cavity sweep is done. The IFO is free now.
  963   Thu Sep 18 12:16:01 2008 YoichiUpdateComputersEPICS BACK

Quote:

Somehow the EPICS system got hosed tonight. We're pretty much dead in the water till we can get it sorted.


The problem was caused by the installation of a DNS server into linux1 by Joe.
Joe removed /etc/hosts file after running the DNS server (bind). This somehow prevented proper boot of
frontend computers.
Joe and I confirmed that putting back /etc/hosts file resolved the problem.
Right now, the DNS server is also running on linux1.

We are not sure why /etc/hosts file is still necessary. My guess is that the NFS server somehow reads /etc/hosts
when he decides which computer to allow mounting. We will check this later.

Anyway, now the computers are mostly running fine. The X-arm locks.
The Y-arm doesn't, because one of the digital filters for the Y-arm lock fails to be loaded to the frontend.
I'm working on it now.
  964   Thu Sep 18 13:05:05 2008 YoichiUpdateComputersEPICS BACK

Quote:

The Y-arm doesn't, because one of the digital filters for the Y-arm lock fails to be loaded to the frontend.
I'm working on it now.


Rob told me that the filter "3^2:20^2" is switched on/off dynamically by the front end code for the LSC.
Therefore, the failure to manually load it was not actually a problem.
The Y-arm did not lock just because the alignment was bad.
Now the Y-arm alignment is ok and the arm locks.
  966   Thu Sep 18 18:38:14 2008 YoichiHowToComputersHow to compile an SNL code for VxWorks
Dave Barker guided me through how to compile an SNL code into a Motorola 162 CPU object.

Here is the procedure:

(1) You need an account at LHO and a password for ops account at LHO. Contact Dave if you don't have these.

(2) Copy your code (say Particle.st) to the LHO gateway machine.
scp Particle.st username@lhocds.ligo-wa.caltech.edu:/cvs/cds/lho/target/t0sandbox0
(3) Login to lhocds.ligo-wa.caltech.edu
ssh username@lhocds.ligo-wa.caltech.edu
(4) Login to control0
ssh ops@control0
(5) Change directory to the sandbox dir.
cd /cvs/cds/lho/target/t0sandbox0
(6) Prepare for the compilation
setup epics
(7) Edit makefile in the directory. You have to modify a few lines at the end of the file.
There are comments for how to do it in the file.

(8) Compile
make Particle.o
(9) Copy the object file to the 40m target directory
scp Particle.o controls@nodus.ligo.caltech.edu:/cvs/cds/caltech/target/c1psl/

That is it.
  972   Fri Sep 19 09:49:42 2008 YoichiUpdateComputerssvn is old
The problem below is fixed now.
The cause was .svn/entries and .svn/format had wrong version number "9" where it had to be "8".
I changed those files in all the sub-directories. Now svn up runs fine.
I don't know how this version discrepancy happened.



Quote:
linux2:mDV>ssh nodus
Password:
Last login: Fri Sep 19 00:11:44 2008 from gwave-69.ligo.c
Sun Microsystems Inc.   SunOS 5.9       Generic May 2002
nodus:~>c
nodus:caltech>cd apps/
nodus:apps>cd mDV
nodus:mDV>svn update
svn: This client is too old to work with working copy '.'; please get a newer Subversion client
nodus:mDV>whoami
controls
nodus:mDV>uname -a
SunOS nodus 5.9 Generic_118558-39 sun4u sparc SUNW,A70 Solaris
nodus:mDV>pwd
/cvs/cds/caltech/apps/mDV
nodus:mDV>
Frown
  977   Mon Sep 22 16:51:27 2008 YoichiHowToComputersNetwork GPIB
I was able to make the wireless connected GPIB interface work with SR785.
Now you can download data from SR785 through network, wherever it is located.
Say good bye to floppy disks.

I wrote an installation note in the wiki.
http://lhocds.ligo-wa.caltech.edu:8000/40m/GPIB

I wrote a new script called "netgpibdata.py" which works similarly as "getgpibdata.py".
It is in the 40m svn. Instructions on how to use it is on the above mentioned wiki page.
  983   Tue Sep 23 00:47:24 2008 YoichiHowToComputersNetwork GPIB

Quote:

I wrote a new script called "netgpibdata.py" which works similarly as "getgpibdata.py".
It is in the 40m svn. Instructions on how to use it is on the above mentioned wiki page.


netgpibdata.py is now installed on the controls machines (/cvs/cds/caltech/scripts/general/netgpibdata/netgpibdata.py).
You can use it like,
netgpibdata.py -i 131.215.113.106 -d AG4395A -a 10 -f spectrum01

In this example, data from Agilent 4395A analyzer at GPIB address 10 connected to the GPIB-LAN box with the IP address 131.215.113.106
is downloaded and saved to spectrum01.dat. The measurement parameters are saved to spectrum01.par.
  991   Thu Sep 25 10:48:29 2008 YoichiUpdatePSLFSS calibration again
I did a calibration of the FSS error signal again with a different method.
This time, I swept the laser frequency with the NPRO PZT around a resonance.
The attached figures show the transmitted light power and the PDH error signal vs the applied voltage to the PZT.
From the width of the transmitted light power peak, we can obtain the PZT voltage to the laser frequency coefficient,
i.e. the HWHM (Half Width Half Maximum) equals to the FSR (38kHz).
Once the PZT is calibrated, the PDH error signal can be calibrated by the fitting the central slope with a line.

I repeated the measurement 8 times and fitted the obtained data to get the HWHM and the slope.
The results are the following:
PZT calibration = 6.3 +/-0.1 MHz/V
PDH calibration = 6.5 +/-0.5 kHz/V

Note:
(1) The calibration coefficient (6.5kHz/V) is almost consistent with the previous value (6.83kHz/V elog:958). However, that calibration
used a considerably different value for the PZT calibration (11.172MHz/V elog:791). The discrepancy in the PZT calibration is understandable
because my previous PZT calibration was very rough. The fact that the two calibrations still agree is a mystery.

(2) In the transmitted power curve, there seems to be a slight distortion, probably due to the thermal effect.
We should reduce the power to the reference cavity to remove this effect.

(3) This measurement was done after Peter installed his RF source. The demodulation phase had not yet been optimized. We should
repeat the calibration after he optimizes the phase.

(4) I used the Tektronix oscilloscope for the measurement.
Using the ethernet-wireless converter, you can connect the scope to the network from anywhere in the lab.
No hard wire required anymore.
Then you can download the data from a web browser. It is cool !
Attachment 1: PDTrans.png
PDTrans.png
Attachment 2: PDHsignal.png
PDHsignal.png
  993   Thu Sep 25 15:24:05 2008 YoichiUpdateIOOMC_F VCO calibration
I calibrated the VCO driving the AOM for the AO path of the MC feedback.

I injected DC voltage to the VCO and measured the output frequency with the SR620.

The attached plot shows the relation between the input voltage to the VCO and the output frequency.
The coefficient is 1.75MHz/V. Since the AOM is double path, the actual actuation efficiency is 3.5MHz/V.
We can use this value for the calibration of the MC_F. However, the MC_F DAQ channel is sampling the VCO input voltage through a 10Hz high-pass filter.
This filter has to be taken into account to convert the MC_F counts to frequency.
I will measure the transfer function from the VCO input to the MC_F counts tomorrow.
Attachment 1: VCO_Cal.png
VCO_Cal.png
  997   Fri Sep 26 14:10:21 2008 YoichiConfigurationComputersLab laptops maintenance
The linux laptops were unable to write to the NFS mounted directories.
That was because the UID of the controls account on those compters was different from linux1 and other control room computers.
I changed the UID of the controls account on the laptops. Of course it required not only editing /etc/password but also dealing with
numerous errors caused by the sudden change of the UID. I had to chown all the files/directories in the /home/controls.
I also had to remove /tmp/gconf-controls because it was assigned the old UID.

Whenever we add a new machine, we have to make sure the controls account has the same UID/GID as other machines, that is 1001/1001.


I did some cleanups of the laptop environment.
I made dataviewer work on the laptops *locally*. We no longer have to ssh -X to other computers to run dataviewer.
The trick was to install grace using Fedora package by
sudo yum install grace
Then i modified /usr/local/stow_pkgs/dataviewer/dataviewer to change the option to dc3 from "-s fb" to "-s fb40m".
  1008   Mon Sep 29 17:53:33 2008 YoichiUpdatePSLISS update
ISS has been saturating easily.
Today I opened the PSL enclosure to inspect the ISS box. Then I found that the sensor PD was disconnected from the box.
I don't know for how long it has been like this, but it is clearly bad.
I connected the PD and I was able to increase the ISS gain to 0dB (from -5dB).
When I turned off the FSS, I was able to increase the gain further up to 8dB. So the FSS must have been doing something bad to the laser intensity.
The FSS fast path did not get huge kicks when ISS was turned on as observed before. But still the FSS fast signal is wondering around about +/-0.3V.
It does not stop wondering even when the ISS is turned off (even if the CS drive cable is physically disconnected).
I will try to optimize the slow servo.

After Peter tried to optimize the demodulation phase of the FSS (see his entry), I was able to increase the ISS gain to 8dB even with the FSS running.
I haven't fully understood what is behind this behavior.

To investigate what is going on in the ISS, I opened the box and inspected the circuit.
I found many innovative implementations of electric circuit components. See the attached photo. It is a three dimensional mounting of
a surface mount AD602 !
Anyway, the board is somewhat different from the schematic found in the DCC. But I roughly followed the circuit.
I will measure open loop TFs and various signals to see how we can improve the ISS.
Attachment 1: IMG_1671.JPG
IMG_1671.JPG
  1017   Wed Oct 1 23:05:14 2008 YoichiUpdatePSLISS RIN spectra
Stefan, Yoichi

We took relative intensity noise (RIN) spectra of the ISS error point and the monitor PD (attm1).
In-loop RIN is the sensor PD and "Out of the loop RIN" is the monitor PD.
The ISS gain slider was at 8dB in this measurement.
It looks normal. 
An open loop transfer function of the ISS loop was measured (attm2). The UGF was 22kHz with the phase margin of ~22deg.
We should increase the UGF up to ~60kHz

When we increase the gain up to 14dB, the CS saturation warning comes up in the EPICS screen.
We confirmed this by monitoring the CS drive signal with an oscilloscope.
It is the output of an AD602J, which has +/-3V output range. 
By increasing the gain of AD602J, we saw that the output signal hits the rail.
There seems to be a lot of high frequency (100kHz - a few MHz) noise, out of the control band.
We also observed that AD602J itself oscillates at about 10MHz (don't remember the exact number) when the gain is increased.
(We saw this even when the loop is off. There is no such an oscillation in the input to the AD602J).
When we took wide band spectra of the CS drive signal, we saw many large harmonics of ~180kHz. We believe these peaks are limiting
our ISS gain now (causing the CS saturation). The harmonics persisted even when we disconnected the PDs. So it is not coming from the light.
We saw the same harmonics in the power lines. They may be the switching noise of the Sorensens. 
We took spectra of those harmonics, but the netgpibdata.py somehow did not save the data from AG4395A correctly. I have to debug this.

Stefan removed DC offsets from the AD829s (many of them are used in the ISS board) by turning the pots for offset adjustment.
This eliminated the problem of getting a large DC CS feedback (observable in C1:PSL-ISS_CSDRIVE_MEAN) when the gain is increased.

During the investigation, I noticed that increasing the PMC gain too much (~22dB) caused an oscillation of the PMC loop and consequently made
the ISS saturate. When the ISS is behaving bad, we should check the PMC gain.

Currently, the ISS is running OK with the gain = 8dB. I modified the mcup script to set the ISS gain to 8dB when the MC is locked.

TO DO:
Wait for Peter's answer about spare ISS boards.
Power line filtering. 
Find the cause of AD602J oscillation (Well this is the one mounted upright. So just mounting it normally might solve the problem :-). 
Attachment 1: RIN.png
RIN.png
Attachment 2: OPLTF.png
OPLTF.png
  1018   Wed Oct 1 23:21:03 2008 YoichiConfigurationPSLReference cavity reflection camera
I re-centered the reference cavity reflection camera, which has been mis-aligned for a while.
I also tweaked an input steering mirror to make the alignment better. This resulted in the increase of the transmission PD voltage
from 8V to 9V.
  1032   Tue Oct 7 21:19:40 2008 YoichiUpdateIOOMC_F calibrated spectrum
I updated the plots because I did not take into account the double path AOM effect, which doubles the frequency actuation efficiency. (2008/10/8)

I determined the MC_F counts to the PSL frequency change calibration.
The attachment 1 is the calibrated MC_F spectrum, which is, above the cross over frequency, equivalent to the frequency noise seen by the MC.

The calibration method is the following:

1) I picked spare AD and DA channels (C1:IOO-MC_TMP1 and C1:OMC-SPARE_DAC_CH_16_EXC). C1:OMC-SPARE_DAC_CH_16_EXC is labeled C1:OMC-OSC_FM on the cable.

2) C1:IOO-MC_TMP1 was calibrated by injecting a sine wave of known amplitude and measuring the amplitude in counts in dataviewer.
It was 63uV/cnt.

3) C1:IOO-MC_TMP1 was connected to the feedback BNC connector of the MC board, that is the direct monitor of the feedback voltage to the VCO.

4) C1:OMC-SPARE_DAC_CH_16_EXC was connected to the channel B excitation input of the MC board, which adds the signal to the fast feedback path.

5) Using DTT a swept sine signal was injected to the MC board through C1:OMC-SPARE_DAC_CH_16_EXC, and the transfer function from C1:IOO-MC_TMP1 to the
C1:IOO-MC_F was measured.

6) Using the calibration of C1:IOO-MC_TMP1, the transfer function from the MC_F count to the actual voltage applied to the VCO input was obtained.
(attm2)

7) Using the DC calibration of the VCO input voltage to the VCO frequency change (1.75MHz/V elog:993) and the fact that there is a 1.6Hz pole and a 40.8Hz zero between the VCO input connector and the actual input of the VCO chip, the final calibration transfer function from the MC_F count to the frequency change of the PSL (that is twice the frequency change of the VCO within the bandwidth of the FSS) can be obtained (attm3).

8) The analytic form of the calibration TF is, poles at [1.6Hz, 11.42Hz, 11.42Hz] and zeros at [40.8Hz, 113Hz, 113Hz] with the DC gain of 110Hz/cnt.
Attachment 1: MC_F-spectrum.png
MC_F-spectrum.png
Attachment 2: VCO_VoverMC_F.png
VCO_VoverMC_F.png
Attachment 3: PSL_FoverMC_F.png
PSL_FoverMC_F.png
  1034   Wed Oct 8 19:17:55 2008 YoichiConfigurationPSLLaser power is slowly recovering
This afternoon we (rich, steve, yoichi) shutdown the laser for the DC-DC converter installation.
(we decided not to do so. Detail will be posted soon.)
After we turned on the laser again,the laser power has been recovering but very slowly.
At the time of writing, the laser power is 2.6W (MOPA_AMPMON).
I think it is because the chiller temparature has not yet settled down (it went up to 25C and slowly coming down, now at 22C).
It will take some hours until the power fully comes back.
Right now I confirmed that at least the MC locks.
  1035   Wed Oct 8 21:26:20 2008 YoichiUpdatePSLAttempt to replace the DC-DC converter (aborted)
Rich, Steve, Yoichi

We opened the MOPA box and inspected our NPRO.
We concluded that this NPRO is different from the ones at the sites.
At the sites, the NPROs have a connector on the board which accepts the output of the DC-DC converter.
Rich's replacement DC-DC converter has a matching connector to it. So replacement of the DC-DC converter is easy.
In our NPRO, there is no such a connector found. The cables coming from the external power supply are directly soldered
on to the PCB (see attm1).

We have to take out the PCB in order to work on it.
As shown in the second picture, there is a D-SUB connector sticking out of the box through the rear panel.
In addition, the PCB is connected to the metal box containing the crystal with an IDE style connector.
This means the PCB is tightly constrained.
To take out the PCB without applying too much stress on it, we have to take off the rear panel.
To do so, we have to remove the screws on the bottom of the NPRO box. That means we have to move the NPRO.
We did not want to do so, because it will screw up the alignment to the amplifier.

The model number of the DC-DC converter looks like NMH0512-something.
According to the datasheet of NMH0512S, the switching frequency is typically 95kHz. We saw 77kHz harmonics in the FSS error signal.
I'm not sure if this is the culprit. I will try to measure the EMI from this guy later.
Attachment 1: DCDC.JPG
DCDC.JPG
Attachment 2: NPRO.JPG
NPRO.JPG
  1036   Wed Oct 8 22:23:43 2008 YoichiConfigurationElectronicsElectronics work bench cleanup
Yesterday, I cleaned up the electronics work bench. I figured that keeping the work bench
in order has larger effect on the work efficiency than buying expensive soldering stations.
Whoever works there should clean up the table after the work to the state shown on
the right side of the picture (at least).
If you leave the bench for a while (more than 30min) but intend to return later and
resume the work, please write your name and time on a piece of paper and put it on the bench.
Otherwise, your stuff can be taken away anytime.
Attachment 1: Cleanup.jpg
Cleanup.jpg
  1037   Wed Oct 8 23:18:23 2008 YoichiUpdatePSLCorrelation between the Sorensen switching noise and the FSS error signal
I took some spectra and coherence function of the FSS error signal and the +24V Sorensen power line.
The first plot shows spectra of the two signals. Looks like Sorensen is not responsible for most of the lines
in the FSS error signal.
The coherence function between the two signals supports it (second plot).
Slight coherence can be seen at 23kHz and 98.4kHz but not significant.

I will check the coherence of the power line with the ISS signal next.
Attachment 1: PowerLineSpe.png
PowerLineSpe.png
Attachment 2: Coherence.png
Coherence.png
  1041   Fri Oct 10 20:03:35 2008 YoichiConfigurationComputersmedm, dataviewer, dtt on 64 bit linux
I compiled EPICS (base, medm and ezca) and dataviewer for 64 bit linux.
These are installed in /cvs/cds/caltech/apps/linux64/.
I also configured cshrc.40m to make it possible to run the 32bit dtt on 64bit machines.
64bit ligotools is also installed to /cvs/cds/caltech/apps/linux64/ligotools although I haven't tested it extensively.

With those essential tools available for 64bit linux, Joe and I decided to install 64bit CentOS to the new linux machine.
It is named allegra.
Now, medm, dataviewer, dtt, awg, foton and ezca commands all work on rosalba and allegra.
I put some notes on how to make things work on 64bit in the wiki.
http://lhocds.ligo-wa.caltech.edu:8000/40m/Building_LIGO_softwares_for_64_bit_linux

I compiled dtt (actually the whole GDS tree) for 64bit linux and the build process finished normally.
But somehow dtt does not work properly. It starts on my laptop but does not retrieve data. It crashes on rosalba.
So I had to retreat to 32bit.
  1044   Mon Oct 13 13:56:03 2008 YoichiUpdatePSLMOPA is not that much in trouble now
The problem was found to be all to do with the shutter.
The shutter started to work again, after a while, apparently for no clear reason.
The alignment to the PA was actually not screwed, and the MOPA output is now slowly increasing.
We figured that the 126MON PD has been mis-aligned for a long time. It was just picking the
scattered light from the output of the PA. So when the shutter is closed, it is natural that 126MON also goes down to zero.
It is a bit difficult to center the beam on the PD because there is not much room for moving the PD.
However, Alberto came up with a configuration (flip the PD and reflect back the beam with a mirror to the PD), which seems to
be feasible. We will do this modification when the MOPA is confirmed to be ok.

Here is more detail about the shutter problem:
The shutter is controlled by the MOPA power supply. There are three ways to command the power supply.
The switch on the front panel of the power supply, the EPICS switch (through a XYCOM XY220), and the interlock.
The ribbon cable from the power supply's back is connected to J1 of the cross connect. The pin 59 of the cable is the one
controlling the shutter. It is then routed to J12 pin 36. The interlock and a XYCOM switch are both connected to this
pin.
Now what happened was, on the way tracking down those cables, I pushed some connectors, especially the ones on the XYCOM.
After that, I was able to open the shutter from the EPICS button.
Steve and Alberto tried the EPICS button many times in the morning without success.
My guess is that it was some malfunctioning of the XY220 accidentally fixed by my pushing of the cables.
But I cannot exclude the possibility of the interlock malfunctioning.



Quote:
Steve, Alberto, Yoichi

A quick update.
The MOPA output went down to zero on Sunday early morning (00:28 AM).
We found that the NPRO beam is mis-aligned on the power monitoring PD (126MON).
We don't know yet if it is also mis-aligned to the power amplifier (PA) because the mechanical shutter is not working (always closed).
Most likely the beam is not aligned to the PA.
A mystery is that although the beam is terribly (more than a half inch) missing the monitor PD, the beam still goes through two faradays.
Another mystery is that the NPRO output power is now increased to 600mW.

The power drop was a very fast phenomenon (less than 1/16 sec).
We are trying to figure out what happened.
The first step is to fix the mechanical shutter. We have a spare in our hand.
  1045   Mon Oct 13 18:59:39 2008 YoichiUpdatePSLNPRO EMI and FSS error signal correlation
I made a simple loop antenna to measure the electro-magnetic inteference (EMI) around the master oscillator NPRO.

The first plot shows the comparison of the FSS error signal with the EMI measured when the antenna was put next to the NPRO (the MOPA box was opened).
There are harmonics of 78.1kHz which are present in both spectra. It is probably coming from the DC-DC converter in the NPRO board.

The second plot is the same spectra when the antenna was put far from the NPRO (just outside of the PSL enclosure).
The 78.1kHz harmonics are gone. So these are very likely to be coming from the NPRO.

The third plot shows the coherence functions between the signal from the antenna and the FSS error signal.
When the antenna was put near the NPRO, there is a strong coherence seen around 78.2kHz, whereas there is no strong coherence
when the antenna is far away from the NPRO.
This is a strong evidence that the 78.2(or 78.1)kHz harmonics is coming from the NPRO itself.

There are many peaks other than 78.1kHz harmonics in the FSS error signal spectrum. For most of them you can also find corresponding peaks in the EMI spectrum.
We have to hunt down those peaks to avoid the slew-rate saturation of the FSS.
Attachment 1: IMG_1692.JPG
IMG_1692.JPG
Attachment 2: Spectrum.png
Spectrum.png
Attachment 3: SpectrumFar.png
SpectrumFar.png
Attachment 4: Coherence.png
Coherence.png
  1047   Tue Oct 14 19:18:18 2008 YoichiUpdateComputersBootFest
Rana, Yoichi

Most of the FE computers failed around the lunch time.
We power cycled those machines and now all of them are up and running.
I confirmed that the both arms lock.
Now the IFO is in "Restore last auto-alignment" status.
  1048   Tue Oct 14 19:24:34 2008 YoichiConfigurationPSLFSS light power reduced
Rana, Yoichi

To change the gain distribution in the FSS, Rana reduced the VCO power for the AOM to reduce the light incident to the reference cavity.
Now the transmitted power of the RC is 2.3V compared to 6.5V before.
The FSS common gain can be increased to 5dB. I haven't changed the normal gain for this slider, so the mcup script will still set
the common gain to 1.5dB after an MC lock.
With this change, we take some gain from the optical part and give more gain in the electronics.
This might relieve the slew rate limit problem if it is happening in an early stage of the electronics.
  1051   Thu Oct 16 09:44:49 2008 YoichiUpdatePSLBad cable for FSS
Yesterday arount 1:30PM, we lost the LO signal for the FSS.
I found it was caused by a bad cable connecting from the peter's RF oscillator box to the LO of the FSS.
I temporarily replaced it with a BNC cable of comparable length.
ELOG V3.1.3-