i updated the database for epics channels for the PSL lab and restarted the framebuilder on fb1.
I didn't restart the framebuilder on fb0, but once it will be restarted it' will load the new channel list too.

I saw that something seems to be wrong with the network as we have several lost packets which also shows up in the saved data.
I will investigate this later as it seems to be a problem for the slow channels from the PSL lab only.

changed setpoint for ACAV to 37.2 degrees, disabled the FSS loop and enabled feedback to laser temp using VCO input signal (C3:PSL-ACAV_VCOMON)

RCAV resonant at -0.1154,  AOM centered at -0.0987

changed the ACAV temp to 37.3 degrees. Both cavities are locked now.

I'll monitor the VCO input signal to center the range by adjusting the temp a little bit more.

i lost lock of both cavities for some unknown reason. Also the crate seemed to stop working as some channels are dead now...

relocked both cavities. The second crate containing the output card to control the ACAV power supply stopped working and i can't login from here. It's blocking the telnet request.

So Tara, plz reboot the crate in the other "rack", above the SR785. Simply push the reset button... Thanks

plz change the channel names. Those names are bullshit...

set temp for the ACAV should be 37.3, that was the value since about a week. see here : http://131.215.115.52:8080/PSL_Lab/307

any results from the poison from 40m they tried in the TCS lab? Did it work?If yes we should get some for the other labs too....

looks like some fault of the database. /usr1/epics/psl/db/acav.db does not contain the correct entry. check rcav.db and copy the record for "C3:PSL-RCAV_TEMPAVG" into acav.db. Then simply change "RCAV" into "ACAV" everywhere for this record. Also change the setpoint for the ACAV in the startup.cmd file to 37.3 and the ACAV-heater value to 4.653. Those are the latest values when both where locked for several hours. Reset the crate again.

made the changes a minute ago. simply reboot after changing the values in the startup.cmd (those i didn't change)

be carefull with the data you are taking right now. it's wrong for your projection as the power fluctuations are different when locking only the ACAV using the AOM. The largest contributor might be the pointing from the AOM itself, which is different if the laser isn't locked to the other cavityat the same time.

Why don't you use the new fast channels you have hooked up last week? And don't forget to change the names of those :-)

can you plz check this channel as it is constantly at -14.4797 since yesterday. Did you disconnect it? If yes, plz elog those things!! Everything must be eloged

if you wanna measure anything in the ACAV loop without the RCAV locked, don't forget to DISABLE the FSS loop.
If you don't, your measurements will be shit as the PC is fluctuating like hell making the laser noisy which can't be handled by the other loops due to limited bandwidth...

was it grey? If yes the cable already connected to the T is the cable going to the DAQ. That's why there is a T already. Don't disconnect any signals without checking in advance what they are and what they are used for. Some of them are required for locking, e.g. the transmitted light is required for the servo as a feedback if it is locked or not for the temp feedback. If you have to disconnect anything do it but put an entry in the elog.

don't change anything until it is stable and you thought about it carefully. The system was totally out of control, check the dataviewer!.
So there is no way to make an estimate for the values as you have no equilibrium!! That takes several hours after ANY change to the system, like rebooting the crate or turning on a temp control loop.
Remember: time constants are several hours!

So be patient and wait until tomorrow or late tonight before you make estimates and changes. Both temperatures are NOT close to their original setpoint and largely fluctuating.
RCAV is at 34.8 instead of 35 and ACAV changed from 37.1 to 37.45 within the last hours.
So no way to make the right adjustments right now, as your laser SLOWDC value does not reflect the actual temperature of the chamber.

Changed it back to the original settings (37.3) as those were working over several days before the system stopped working properly...

 Frank, did you remotely change ACAV_SETPT back to 37.3? I came back and it was back to 37.3.

i tried to figure out where the network problems come from. Looks like it's the fiber connection between fb1 and the switch in the PSL lab.

Here a result from a simple ping between fb1 and the other computers. It acrually doesn't matter which one.

--- 10.0.0.1 ping statistics ---
1000 packets transmitted, 817 received, 18% packet loss, time 201397ms
rtt min/avg/max/mdev = 0.169/0.233/0.381/0.025 ms

--- 10.0.0.2 ping statistics ---
1000 packets transmitted, 786 received, 21% packet loss, time 202036ms
rtt min/avg/max/mdev = 0.617/0.694/2.658/0.152 ms

--- 10.0.0.3 ping statistics ---
1000 packets transmitted, 796 received, 20% packet loss, time 201696ms
rtt min/avg/max/mdev = 0.410/0.453/2.655/0.081 ms

Pings between computers within the PSL lab but connected to the same switch are OK:

--- 10.0.0.1 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 202998ms
rtt min/avg/max/mdev = 0.000/1.092/13.755/1.340 ms

--- 10.0.0.2 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 203161ms
rtt min/avg/max/mdev = 0.200/1.719/13.230/1.545 ms

So i think it's the fiber connection.

 

after a lot of test it turned out that the optically contacted QWP/PBS combinations used for the reference cavity so far are very bad alligned.
We tested two out of three we have in the PSL lab and both are bad, meaning about 10% of the linear polarized light entering the PBS are not converted into circular polarized light and so not reflected when comming in the reverse direction. By replacing the optically contacted version by individual PBS and QWP the amount of wrong light dropped by a factor of 100 or so.

Replacing the bad optics should reduce the effect from backscattered/reflected light, which increases the RIN a lot at low frequencies. It doesn't seem to be the laser itself, as with none, one or two FI the spectrum seems to be the same bad level when light is reflected back into the PMC. It looks like the source is the PMC itself or it's control loop.

So, Tara is replacing the bad ones and re-aligning everything. Temp is good, both cavities are resonant at the same time so i hope we can get new/better data tomorrow.

i have several channels, e.g "C3:PSL-RCAV_RCPID_SETPOINT", loaded on the VME system as software channels.

If i try to access those channels from the VME console everything is fine.

psl1> dbpr "C3:PSL-RCAV_RCPID_SETPOINT"
ASG :               DESC: SETPT- set point                  DISA: 0            
DISP: 0             DISV: 1             NAME: C3:PSL-RCAV_RCPID_SETPOINT       
OMOD: 0             OVAL: 0             RBV : 0x0           RVAL: 0x0                 
value = 0 = 0x0

If i try to use commands from any other machine, e.g. ezcaread for the same channels i get the message  "channel not accessible".
At the same time the VME system throws the following exception on the console.

psl1> task: 0Xca8f00 CA client
Illegal Lock Set Lock Set out of range:dbScanLock
task: 0Xf9f7f8 taskwd
task ca8f00 CA client suspended

This only happens to some channels. I don't see a system except that the channel names are long, but not longer than working ones. For R3.13 the name must be <= 28 characters, For R3.14 the name must be <= 60 characters.

What's the problem?

workers finished the piping stuff for today but have to come back to connect it to the stuff one floor above. It's not the sprinkler stuff, it's heating water.
So some other guys will show up in the future to drill holes for the sprinkler pipes and installation of the sprinklers.

turned the laser back on

rebooted the PSL crate to see if it fixes the problem with some of the channels inaccessible from external computers

all channels are working now

some more photos for Koji and Tara about the foam insulation and temp sensor location

some additional information:

the beat noise was measured as the feedback signal to the VCO of the PLL, so the calibration factor does not change with changing optical power, alignment, mixers etc.
It's a convenient way to change individual things in the setup and be able do directly compare the measurements without lots of calibration.
We checked the following things:

• power level on beat PD
• different PD with much more bandwidth
• different mixers

The feedback signal is only valid until about 10k. Tara will measure the UGF again on Monday but the signal above 10k exactly scales with power on PD or gain settings while below it stays constant which is exactly what we expect when having enough loop gain in the PLL loop.

Looking more into detail in the spectrum we looked from some tens of Hz to 10k and then tried to excite the spectrum. We could clearly identify the individual resonance peaks from e.g. the beam splitter mount of the beat setup. We know that the way it is set up is very bad but nevertheless we expect mainly lots of resonance peaks but not this hump shaped spectrum.
Now the interesting part is that if we excite the surface of the optical table by touching it softly with e.g. a balldriver we can excite those resonances. What i found very interesting is if you excite the bottom of the table we excite the hump very broadband. You only have to touch it barely like tipping with your fingertips and the whole hump increases. So my guess is that we have a scatter source somewhere which would also explain the shape (at least from my experience).

So the plan for Monday is to have a closer look on that, then checking all the wholes in the foam insulation and probably make them little bigger (right now they are 1/2 inch). Other things are reducing the power from the laser (something we wanna do anyways in the long term), replacing the PMC which scatters a lot of light (you actually don't need an IR viewer to see that, detector card is enough) by a good one and getting a symmetric layout with two periscopes (simple ones like we have now on the other side of the cavity, we casn replace them later by real good ones) for the beat at a lower beam height  to reduce all resonances to better see where/what the underlying noise floor looks like.

very interesting. ACAV was a brand new cavity when we installed it, coming from the same batch as all other LIGO refcavs. When we unpacked the cavity from the original REO tube you could smell the softeners from the plastic. It was sitting more than 10 years in that tube. But as this is/was the only spare cavity we had no choice and installed it. Later i forgot to check the real finesse as the scans showed a finesse close to what it should be and we never spent time on that again.

• replace windows on acav chamber by ar-coated windows
• find source of reflection in cavity - my guess it is the dirty coating - the spot size is about 1cm, so it can't be a pure reflection from any of the other surfaces as the beam is too large. The concave mirror surface acts like a convex surface in reflection and intensity increases when cavity is locked.
• clean mirrors of current cavity, replace mirrors or replace entire cavity
• clean all optics on table - entirely and double check with real bright white-light source
• make acav RFPD resonant or wait for new RF photodiodes to be ready
• tune PMC RFPD to 21.5MHz (easy)
• add AOM in RCAV path (doesn't help right now to lower phase noise or increase range of PLL)
• lower beam height for beat setup in transmission
• replace RFPD for pll by larger size PD
• add notch for PMC
• replace current FSS stuff by adv LIGO version
• check max tuning range for wenzel vco
• add perl script for temp feedback to acav to keep beat constant (long term stability)
• replace LO for ACAV and RCAV by real sinewave (wenzel+amplifier)
• change gain in RFPDs for 1mW max light
• measure seismic on table
• float table to see what happens (75PSI are not enough, tested today)
• ...

got some 2mm InGaAs photodiodes from Peter. So we can go ahead and replace the dirty one from the ACAV RFPD tomorrow and re-tune it to 35.5MHz.

The ACAV RFPD stopped working this afternoon. It had high current consumption on the +15V supply, causing the supply to drop down to 2.3V.
I turned out that the logic IC (U8, see schematic) was broken and so the +5V (internally regulated) caused the high current flow which is supplied from the +15V.
I removed U8 entirely as we don't need it. Pin7 of U2 can be left open according to the datasheet in order to enable the device. Diode is now working again.

Already yesterday we made several changes in order to make the RFPDs for both cavities the same. Basically more DC and AC gain.
Attached the modified schematic (only page 1) for ACAV RFPD. Changes are in red.

for fb2 from outside is

131.215.114.84

found a nice calculator here:

http://vk1od.net/calc/tl/tllc.php

which has a huge amount of different cable types in it's database. Checked/compared the calculated values for some examples given in several datasheets found on the web and they are close within each other.
Here an example for our current case for the 500ft spool of RG58C/U we have in the lab. Loss is only 32dB which looks pretty good to me for that cheap cable.

added the VCO feedback signal to the FB. We had it connected but not written into the frames so far

Channel name is C3:PSL-ACAV_VCOMON

I've measured the TF of 500ft of RG58C/U cable to see if the loss is about the same calculated by that piece of software i've found.
I've measured 33.4dB attenuation for the LCOM cable, the calculated value is 32.1dB for some unknown RG58C/U cable.
So i think we should go ahead and calculate the required length and try it.

This is a picture of the 500ft spool we have. As you can see there is only about 1.5inch on that spool, the rest is empty. Height is a few inches.
So regarding the size we can easily have several 100m of cable in a small package

2 stretches of data taken at the following UTC times:

11/2/2 23:18:19  duration: ~9min

11/2/2 23:22:50  duration: ~9min

units for data: volts  SCALE: 10kHz/V

Here a screenshot for the first stretch from dataviewer:

 here the data:

 we didn't take longer timeseries with more range as the resolution is so bad that it couldn't be used to extract a spectrum down to mHz .

RAW data can be accessed via 131.215.114.84:8088 or SSH-login and doing the usual.
Channel name is C3:PSL-FSS_FREQCOUNTER

changed the frequency noise readout to the cable-delay version to see how it works.
As the loss of the cable is very large and the signal from the photodetector not very strong i had to add some amplifiers for signal conditioning (see figure below).
Data is acquired with channel C3:PSL-FSS_FREQCOUNT in replacement for the frequency counter. Started taking data around 11/2/4 4:16:30 UTC.
Will do final calibration tomorrow. First test gave signal from mixer changes from peak-to-peak for about 600kHz (+/-10%) in frequency change.

 This setup has too much gain (i.e. not enough range). Please reduce the arm length asymmetry by a factor of 10 so that we can monitor over 24 hours.

Also the temperature channels ought to be calibrated (via the EPICS .db) so that the readout is in degC instead of ARB.

exchanged the 500ft spool by a shorter cable to get more range (but less resolution).
Due to the lower losses of the cable i also removed the 2W amplifier.
Right now both cavities can't be locked at the same time, they are slightly out of range.

RCAV is resonant at 0.1958 for the slow actuator, ACAV is resonant at 0.1930

max range for VCO is reached at 0.1948

i've changed the RCAV settemp a little bit and will keep an eye on that and we will hopefully be back online tonight

locked both cavities. Current slowdc value is 0.1925. VCOmon is -2.2V. Changed RCtemp to 35.00.

Data is valid since 11/2/6 10:10:00 UTC

stopped taking data for data calibration at 11/02/07 23:35:00 UTC

used two frequency ranges to calibrate the mixer signal

1. calibration factor is 6.85MHz_pkpk measured between 150MHz and 160MHz
2. calibration factor is 6.42MHz_pkpk measured between 147MHz and 154MHz

those numbers should be sufficient for comparison with the VCO feedback signal.

tried to fit  the tuning of the VCO in order to calibrate the VCO tuning voltage into frequency shift.
I've only fitted it down to -4.3V using 5 degrees as there is no change in frequency below that point anymore.
Will add an EPICS software channel which contains the calibrated data.

Linear model Poly5:
     f(x) = p1*x^5 + p2*x^4 + p3*x^3 + p4*x^2 + p5*x + p6
Coefficients:
       p1 =   0.0005513
       p2 =   -0.003731
       p3 =   -0.005932
       p4 =    -0.02587
       p5 =       1.406
       p6 =       79.99

Using 9 degrees the fit is not as good in the valid region for the 5 degrees, but covers the entire range from -5V to 5V

Linear model Poly9:
     f(x) = p1*x^9 + p2*x^8 + p3*x^7 + p4*x^6 +
                    p5*x^5 + p6*x^4 + p7*x^3 + p8*x^2 + p9*x + p10
Coefficients:
       p1 =   4.16e-006
       p2 = -1.095e-006
       p3 =  -0.0003138
       p4 =   0.0003221
       p5 =    0.007185
       p6 =    -0.01047
       p7 =    -0.05412
       p8 =    0.006482
       p9 =       1.498
       p10 =       79.97

channel name is C3:PSL-ACAV_VCOMON_CAL, calibrated in MHz using the fifth order polynomial equation at the moment.
Unfortunately the field length for the EPICS CALC record is limited (but not mentioned anywhere in the manual !) so the 9th order equation is too long

will change that later to 2 channels for calculating parts of the equation each and then finally combining those parts in a third record to C3:PSL-ACAV_VCOFREQ

the configuration is currently running with a softIOC in /caltech/target/SoftIOC/ on fb2, the database is PSL.db.
Will move that on the VME crate when we reboot the crate the next time.

Currently two channels are defined: C3:PSL-ACAV_VCOMON_CAL and C3:PSL-ACAV_VCOFREQ

C3:PSL-ACAV_VCOMON_CAL contains the polynomial fit for the VCO monitor voltage, which is good for -4.3V to 5.0V in tuning voltage.
To extend the range down to -5V i've used a second calc function named C3:PSL-ACAV_VCOFREQ.
The frequency value where the polynomial function crosses the measured function of the VCO tuning is about 71.6MHz.
As the tuning range ends here the change in frequency for even smaller tuning voltages is almost zero.
So the second function simply checks if the frequency is greater. If so, the output is the polynom. If smaller the value is fixed to 71.6MHz.

Both channels are written to the frames from now on.

PSL.db:

record(calc,"C3:PSL-ACAV_VCOMON_CAL")
{
        field(SCAN,".1 second")
        field(DESC,"VCO frequency")
        field(EGU,"MHz")
        field(PREC,"4")
        field(HOPR,"90")
        field(LOPR,"70")
        field(INPA,"C3:PSL-ACAV_VCOMON.VAL")
        field(INPF,"0.0005513")
        field(INPG,"-0.003731")
        field(INPH,"-0.005932")
        field(INPI,"-0.02587")
        field(INPJ,"1.406")
        field(INPK,"79.99")
        field(CALC,"F*A^5+G*A^4+H*A^3+I*A^2+J*A+K")
}

record(calc,"C3:PSL-ACAV_VCOFREQ")
{
        field(SCAN,".1 second")
        field(DESC,"VCO frequency")
        field(EGU,"MHz")
        field(PREC,"4")
        field(HOPR,"90")
        field(LOPR,"70")
        field(INPA,"C3:PSL-ACAV_VCOMON_CAL.VAL")
        field(INPB,"71.6")
        field(CALC," A>B?A:B")
}

i analyzed  the data taken with the short cable and compared it to the signal from the tuning input to the VCO.
I used the 9.order polynomial fit from yesterday to convert the VCOMON voltage into absolute VCO frequency.
The beat frequency is then twice that frequency.

On the other hand the cable-delay technique was sampled with channel FREQCOUNT.
I've measured the peak voltage of the amplified mixer response to be about 4.52V.
The frequency change which corresponds to peak-to-peak change in output signal (see yesterdays entry) i've used is the smallest value i measured ( 6.42MHz).

Using the sampled data, divided by 4.52V, taking sin^-1 of that and multiplying it by 6.41MHz /2 gives the measured frequency change.
As i don't get an absolute frequency from that measurement i added an offset of 151.5MHz (this information is from the VCO's absolute frequency) in order to compare the fluctuations with the VCO signal.

RESULT:  beat signal fluctuations over a long period of time can be measured using the VCO feedback signal.
                Both signals absolutely agree except for the region where the mixer signal is at it's peak and so the slope is close to zero and so the uncertainty is too large.

Here the plot:

Matlab-code:

t0 = tconvert('02/06/2011 10:10:00');
dur = 3600*24*1;

chans = {...
'C3:PSL-ACAV_VCOMON',...
'C3:PSL-FSS_FREQCOUNT',...
};

y1 = get_trend(chans{1},'minute',t0,dur);
y2 = get_trend(chans{2},'minute',t0,dur);

y1.data = y1.mean;
y2.data = y2.mean;

y1.data = 2*fittedmodel2(y1.data);
y2.data = 151.5-asin(y2.data./4.52).*3.21;

t1 = linspace(0,dur,dur*y1.rate)';
t2 = linspace(0,dur,dur*y2.rate)';

figure(1)
plot(t1,y1.data, 'r',t2,y2.data, 'b')
xlabel({'time [s]'});
ylabel({'beat frequency [MHz]'});
grid

by tuning the servo Tara unlocked both cavities and they are out of range right now, so plz no more temp servo tuning until further notice

shorter cable: cable length 62 inches

amplified (DC-coupled) signal from mixer using SR560, LP@30Hz, gain20 in channel C3:PSL-GEN_DAQ15

185.0MHz :  -2.405V
154.2MHz :   0.005V
123.2MHz :   2.263V

max range of double-passed VCO signal: 142MHz-170MHz

142MHz :  1.38V
170MHz : -1.685V

As the FET preamp need some more time to set up i added the AC-coupled signal using a SR560, gain 10k, LP30Hz into C3:PSL-GEN_DAQ16

FET pre-amplified signal will be connected to C3:PSL-GEN_DAQ14   preamp broken

data taken at 02/06/2011 10:10:00 UTC, duration = 24h

updated plots:

data files:

structure of data files like this:

y1 =
   name: 'C3:PSL-ACAV_VCOMON'
   min: [1440x1 double]
   mean: [1440x1 double]
   max: [1440x1 double]
   rate: 0.0167
   start: 981022215
   duration: 86400
   data: [1440x1 double]

raw data in min/mean/max
calibrated (mean) data in data

some old designs i've built some years ago using the cheaper DIP versions of the matched BJT pairs from Analog Devices.

Designs are DC-coupled, gain 1000 as they were designed for measuring the noise of photodetectors.
Given values are not 100% what i've used later, only for drawing the schmatics (e.g. gain setting resistors or compensation), but order of magnitude is right.

Eagle-files + Documentation:

plots are not taking the change of transmitted PD power when changing VCO frequency into account !

setup and cal data from post #485