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

looks like a fu**** up the data aquisition with the short cable, but i don't know how.

When trying to calibrate the data taken i realized that something was totally wrong as i got some khz/rHz but i couldn't find the mistake.
So i thought the gain setting if the preamps must be different than i wrote down but they are not.
So i checked the calibration again, this time in 1MHz steps all the way through the system but everything was/is OK.
Got almost exactly the same mixer response vs frequency tuning and also the dc-coupled signal was what i measured before.

Here the problem:

The VCO feedback signal gives us a rough idea what frequency we have, which i checked over and over again and matches the frequency counters we have.
The problem is that the DC signal (already amplified) for pi in phase change goes from something like 2.3V to -2.4V.
The same signal from end to end of the VCO goes from -1.7V to 1.4V, see here.
I measured this several times, last week and today and this is fact whatever equipment i use (scope, multimeter, DAQ).

So now the funny part:

The DC signal and the VCO monitor signal look almost identical (shape, uncalibrated).
As i checked  the calibrated (fitted) VCO monitor signal reflects the beat signal within 100kHz or so, but 1MHz for 100% sure.
Now, taking the recorded DC-signal from the mixer from 35h of data and using the calibration (which i did several times) the beat frequency is out of range of the VCO, totally different !
The recorded signal does not match the VCO signal at all! Using the same coefficient to calibrate the spectrum recorded with the AC-coupled amplifier the noise is way to high, higher than everything we had before.
So i took the VCO monitor signal, assuming it is right and showing me the absolute beat frequency and calculated the right coefficient for the mixer signal, which is something like 5MHZ/V instead of 170MHz/V.
Done that, comparing both time series looks fine.
Taking this coefficient to calibrate the spectrum then gives, at least for a the features around a couple of Hz the right level we measured several times before.
The lower frequencies are dominated by the noise of the preamp, so no comparison possible.
So i don;t know what's wrong because i can't reproduce what we recorded. Everything looks the same as last week, checked over and over again. But the DAQ shows something different.

RESULT:

As we can't trust whatever we recorded we redo the measurement. After bringing back the 4-way splitter to 40m i'm using 2-way splitters now instead, increased the signals where possible and the gain of the preamp. re-calibrated everything and triple checked, taking another measurement over night. We will see tomorrow....

Plots, 32h data stretches.
noise plot shows spectrum of data taken with and without 30mHz high pass correction

Found at least two (minor) problems:

1. So far i measured the zero-crossing of the mixer signal and both peak values and modeled the signal using a sine.
   For calibration i used the slope of the sine near the zero-crossing.
   As the frequency range for pi in shift is about 60MHz the function is almost linear for the range we measure over 24h (~2MHz).
   Today i measured the mixer signal in small steps and compared both techniques. The result surprised me a little bit:
   

 

it is not a lot of difference in slope but it is surprisingly linear over a range of 40MHz!

2. the channel which contains the calibrated VCO monitor signal uses a wrong sign.
   The fit is right, but i remembered that i exchanged the BNC to 2-pole LEMO connector some time ago because it had the wrong sign.
   However, the frequency tuning curve i measured with the old (wrong) cable.
   I used the right sign on my computer but implemented the wrong one in EPICS, so that data was/is wrong. Will change that tomorrow.
   This can't explain the problems i had last week as i used Matlab to convert the monitor signal into frequency, not that channel.
   Anyway, this is how the data i took last night (19h) looks like using the right slope (see item 1):
   
   so i think once the EPICS channel is fixed we can trust that channel

to have real data for comparison i measured the noise of the SR560 for different (high) gain settings.
Will add lower gain settings and line powered measurements later.

test setup: SR560, AC-coupled, low-noise setting, battery powered measured with SR785

datafiles contain raw output noise values, so for input referred noise plz divide by gain given in filename. first col = frequency, second col = noise spectral density

yes, for yesterdays measurements 7.435 MHz/V.

But that number changes from measurement to measurement as i'm changing the setup every time to improve SNR (or bring back stuff i've stolen from 40m)

this afternoon the framebuilder (and/or the NDS server) stopped for unknown reasons. We could see real data with Striptool but the framebuilder only saw old, non-changing EPICS values and was still writing them.
Rebstarting the daqd didn't help so i rebooted fb2 and the problem was gone. For some reason we have to manually start daqd und nds, but not a big deal every 6month or so. I also restarted the SoftIOC still running on fb2 which provides the calibrated VCO feedback signal

I had a closer look into effects caused by power fluctuations. To summarize : It is easy to measure TFs from power fluctuations to any other point in the system. SNR is good to very good.

I mainly focused on the effect of changes in shape of the TF from power fluctuations into changes of the beat frequency when changing the power levels anywhere in the system, especially in the cavity paths.
After playing a couple of hours and getting a feeling for what's going on i finally realized that only if changing the power in the ACAV-path strange things happen. This includes changing the total power going to both cavities as well. As taking TF's is taking too long at low frequencies i decided to switch from swept sine measurements to a simple digital modulation of the laser power with 100ms period. This is slow enough to see thermal effects in the cavity and other strange things which i will show below.

For the first set of measurements i reduced the power to the REFCAV path to about 460uW. The total modulation is very large, about 15.6%. The max power to ACAV was about 5.76mW, which i reduced later.
The following graphs shows the response of the beat signal to the digital modulation, beat signal calibrated to Hz, modulation signal a.u.., but the amplitude didn't change between measurements.

 on the left graph (measured at very low power) one can see that the power modulation causes a sudden changes in frequency of the beat signal.
This can be caused by everything producing an offset in the EP which depends on power, e.g. RF-AM, higher-order modes in reflection etc. Nothing unusual so far.
 If the optical power going to the ACAV is increased one can find a point where the change in frequency is almost gone, showed in the center graph.
When the power in increased further the sign of the frequency shift changes! Now some thermal effect becomes dominant, most likely the cavity as the period is 10s and after 5s equilibrium isn't reached.

Now this explains everything i saw before: When measuring the TF from power fluctuations to frequency shift and varying the power the shape of the TF changed because we have two different effects which can even cancel at the right power level send to the cavity!

As we know already that the size of the error signals is too tiny this effect will probably be almost gone once we fixed the demodulation for ACAV. I tried to reduce it a little bit by re-aligning the cavity but no luck - it's already aligned very well. I didn't try the EOM asthis changes the alignment to the other cavity as well and i was to lazy to re-align everything

rebooted it

after rebooting both crates i found that the perl script parameters for both loops are inconsistent with what's documented in the elog here.

Tara, can you plz check what the right numbers are. The numbers in the startup script are totally different from the values you posted.