40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 98 of 330  Not logged in ELOG logo
ID Date Author Type Category Subject
  11714   Mon Oct 26 18:59:25 2015 gautamUpdateLSCGreen beatnote couplers installed

I found (an old) 10 dB coupler in the RF component shelves near MC2 - it has BNC connectors and not SMA connectors, but I thought it would be worth it to switch out the 20dB coupler currently on the X green beat PD on the PSL table with it. I used some BNC to SMA adaptors for this purpose. It appears that the coupler works, because I am now able to register an input signal on the X arm channel of the digital frequency counter (i.e. the coupled output from the green beat PD). I thought it may be useful to have this in place and do an IR transmissions arm scan using ALS for the X arm as well, in order to compare the results with those discussed here. However, the beat note amplitude on the analyzer in the control room looks noticeably lower - I am not sure if the coupler is responsible for this or if it has to do with the problems we have been having with the X end laser (the green transmission doesn't look glitchy on striptool though, and the transmission itself is ~0.45). In any case, we could always remove the coupler if this is hindering locking efforts tonight. 

  11713   Mon Oct 26 18:10:38 2015 IgnacioUpdateIOOLast Wiener MCL subtractions

As per Eric's request, here is the code and TF measurement that was used to calculate the MC2 FF filter that is loaded in FM5. This filter module has the filter with the best subtraction performance that was achieved for MCL.

code_TF.zip

Attachment 1: code_TF.zip
  11712   Sat Oct 24 12:34:43 2015 gautamUpdateCDSFrequency counting - workable setup prepared

Sorry for the confusion - I did mean Green beat frequency, and I had neglected the factor of 2 in my earlier calculations. However, the fit parameter "c" in my fit was actually the half-width at half maximum and not the full width at half maximum. After correcting for both these errors (new fit is Attachment #1, where I have now accounted for the factor of 2, and the X axis is the IR beat frequency), I don't think the numbers change too much. It could be that the frequency counter wasn't reading out the frequency correctly, but looking at a time series plot of the frequency counter readout (Attachment #2), and my earlier trials, I don't think this is the case (38 MHz is a frequency at which I don't expect much systematic error - also, the offset was stepped from -3 to 3 over 45 seconds). 

The revised numbers:

Fitted linewidth = 2*c = 10.884 kHz +/- 2 Hz (95% C.I.)

FSR of Y arm (from elog 9804) = 3.9468 MHz +/- 1.1 kHz

=> Y arm Finesse = FSR/fitted linewidth =  362.6 +/- 0.5

Total round trip loss = 2*pi/Finesse = 0.0173

 

Attachment 1: Yscan.pdf
Yscan.pdf
Attachment 2: Frequency_readout.pdf
Frequency_readout.pdf
  11711   Fri Oct 23 21:58:10 2015 ranaUpdateSUSMC2 F2P mis-tuned

The OSEMs cannot be used for coil balancing above ~10 Hz. The main coupling path from OSEM drive to sensor is not through the mirror motion, but instead direct electrical coupling of the drive wires to the sensing wires.sad

I put this in the elog every ~1-2 years since people keep trying it, but it keeps coming back like a zombie.crying

Better to use the MC angular sensors for L2A decoupling. Not perfect, but better than OSEMs. For the TMs we can use the OLs.

  11710   Fri Oct 23 19:27:19 2015 KojiUpdateCDSFrequency counting - workable setup prepared

It is a nice scan. I'm still thinking about the equivalence of the moving average and the FIR low pass that I have mentioned in the meeting.

Anyways:

I'm confused by the plot. The bottom axis says "green beat frequency".
If you scan the IR laser frequency by df, you get 2*df shift of the green beatnote. You need to have this factor of two somewhere.
If you are looking at the IR beat freq, just the label is not correct. (I believe this is the case.)

Accepting the rather-too-low finesse of 363 (nominally 450), the total round trip loss is said to be 0.0173.
If we subtract the front transmission of 1.38% (and ignoring the transmission loss from the ETM),
the round trip loss is 3500ppm. Is this compatible with the following elog?
http://nodus.ligo.caltech.edu:8080/40m/11111
In fact, I'm afraid that the loss number in the above elog 11111 was not correct by a factor of 10.
Then, if so, can we believe this high loss number? (Nominally we expect ~100ppm loss per round trip...)

  11709   Fri Oct 23 18:36:48 2015 gautamUpdateCDSFrequency counting - workable setup prepared

I've made quite a few changes in the software as well as the hardware of the digital frequency counting setup.

  • The main change on the software side is that the custom C code that counts intervals between successive zero crossings and updates the frequency output now has a moving average capability - the window size is readily changable (by a macro in the first line of the code, which resides at /opt/rtcds/userapps/release/cds/c1/src/countZeroCrossingWindowed.c - however, changing the window size requires that the model be recompiled and restarted), and is currently set to 4096 because based on some empirical trials I did, this seemed to give me the frequency output with the least jitter, and also smaller systematic errors than in my earlier trials described here.
  • The filter modules for both the X and Y channels now have 2 pole butterworth low pass filters with poles at 64Hz, 32Hz, 16Hz, 8Hz, 4Hz, 2Hz and 1Hz loaded. Again, based on my empirical trials, a combination of a moving average filter in the C code and the IIR filters after that worked best in terms of reducing the jitter in the frequency readout. I think the fact that the moving average 'spreads' the impulse caused by a glitch in the counting algorithm improves the response of the combination as compared to having only the IIR filters in place. 
  • The Frequency Counting SIMULINK block has been cleaned up a little - I have removed unnecessary test points I had set up for debugging, and is now a library part called "FC".
  • After the experience of having C1ALS crash as noted here, I was doing all my testing in the C1TST model. Having made all the changes above, I reverted to the C1ALS model, which compiled and ran successfully this time.
  • On the hardware side, I interchanged the couplers mentioned here - so the 20dB coupler now sits on the X green beat PD, while the 10dB coupler sits on the Y green beat PD. This change was motivated by wanting to test out the digital frequency counting setup by performing an arm scan through an IR resonance using ALS, and we found that the PSL+Y green beat frequency was better behaved than the X+PSL combination.

Arm scan

Eric helped me test the new setup by doing an arm scan through an IR resonance by ramping the ALS offset from -3 to +3 with a ramp time of 45 seconds. The data was acquired with the window size of the moving average set to 4096 clock cycles, and a 2 Hz low pass IIR filter before the frequency readout. Attachment 1 shows a plot of the data, and a fit with a function of the form trans = a/(1+((x-b)/c)^2), where a = normalization, b = center of lorentzian, and c = linewidth (FWHM) of the peak (the fitted parameter values, along with 95% confidence bounds are also quoted on the plot). In terms of the data acquisition, comparing this dataset to one from an earlier scan Eric did (elog11111) suggests that the frequency counting setup is working reasonably well - at any rate, I think the data is a lot cleaner than before implementing the moving average and having a 20Hz lowpass IIR filter. In any case, we plan to repeat this measurement sometime next week during a nighttime locking session. It remains to calculate the arm loss from these numbers analogous to what was done earlier for the X arm.

Calculation of loss:

Fitted linewidth = 10.884 kHz +/- 11Hz (95% C.I.)

FSR of Y arm (from elog 9804) = 3.9468 MHz +/- 1.1 kHz

=> Y arm Finesse = FSR/fitted linewidth =  362.6 +/- 0.5

Total round trip loss = 2*pi/Finesse = 0.0173

 

 

 

 

Attachment 1: Yscan.pdf
Yscan.pdf
  11708   Fri Oct 23 09:55:50 2015 SteveUpdateLSCstable days
Attachment 1: stable4days.png
stable4days.png
  11707   Thu Oct 22 08:52:04 2015 SteveUpdateVACclean RGA scan after sweaty Maglev

Clean comparable scan at vacuum normal. There was no backstreaming.

Attachment 1: clean_scan.png
clean_scan.png
  11706   Wed Oct 21 15:42:56 2015 SteveUpdateVACvacuum gauge check

Convectron gauge check:

Brand new 10 years old convectron gauge at atm was swapped into the place of existing gauges to see if they read close to 760 Torrs

They did reasonable well at the low end. I tried to imitate calibration and bring down the high end with little success.

( P1 and P2  were reading 7e-4 to ~660 Torr  The correction of the upper end pushed up the lower end too. I will correct this later

P3 and P4 high ends are way off )

The point is that they work.  Convectron gauges will be replaced and calibrated at the next vent.

Interlocks were not triggered during this test. I was expected to close the PSL shutter when P1 was reading 760 Torr

This hide some problem or  not understanding.

It was good to see CC1 and CC4 working at the moment

 

Somehow I succeded opening VM1 and closed VM2 = vacuum normal

I just hope it stays open overnight to get comparable RGA scan.

 

Attachment 1: Gauges.png
Gauges.png
  11705   Wed Oct 21 10:03:15 2015 SteveUpdateVACafter running out of N2

 

Quote:

[ericq, Gautam, Steve]

Following roughly the same procedure as ELOG 11354, c1vac1 and c1vac2 were rebooted. The symptoms were identical to the situation in that ELOG; c1vac1 could be pinged and telneted to, but c1vac2 was totally unresponsive. 

The only change in the linked procedure was that we did not shut down the maglev. Since I unwittingly had it running for days without V4 open while Steve was away, we now know that it can handle shorter periods of time than that...

Upon reboot, many channels were readable again, unfortunately the channels for TP2 and TP3 are still blank. We were able to return to "Vacuum normal state," but because of unknowned communication problems with VM1's interlock, we can't open VM1 for the RGA. Instead we opened VM2 to expose the RGA to the main IFO volumn, but this isn't part of the "Normal" state definite, so things currently read "Undefined state".

Precondition:

1, Pressure gauges had no communication ( NO COMM ) with c1vac2

 

2, Lost N2 supply on Oct 9 This triggered a normal all valve closed condition. At this point you replace N2 cylinders and manually swich valves to recreate VAC NORMAL configuration in the correct sequential order.

   The very last thing you do is open V1 gate valve.

   a, check TP2 that is the forepump of the Maglev. Foreline pressure to drypump  ~ 10- 100 mTorr, rotation speed 50 Krpm

   b, open V4 if P2 <1Torr

   c, check Maglev rotating at 560 Hz

   d, open V1 if P1 <500 mTorr

   e, check TP3 foreline, rotation speed and open V5 if P3 <1 Torr with VA6 closed

   f, open VA6 if PAN <1 Torr

  g, open annulos valves one by one , like VASE if PASE <1 Torr and so on...........Now the Current State: should read Vac Normal

 

3, Maglev run for 7 days with V4 closed. This encreased its foreline pressure to estimated few Torrs  and its body temp rose ~30C on the outside.

   So it was sweating and it may be back streamed.

The present RGA data is indicating that it had to be very mild.

The RGA will have better sensitivity with VM1 open and VM2 closed.

The PSL output shutter stayed open during these period is pointing  to IFO pressure stayed P1 <3 mTorr

PROBLEM: P1 and P2 plot should show nothing where there is no communication.http://nodus.ligo.caltech.edu:8080/40m/151016_182003/oct16Fpm2015.png

                   How do we check if pressure based software interlocks are working in this no communication condition?

Attachment 1: 1d_after_reboot.png
1d_after_reboot.png
  11704   Tue Oct 20 17:36:01 2015 gautamUpdateCDSFrequency counting with moving average

I'm working on setting up a moving-average in the custom C code block that counts the zero crossings to see if this approach is able to mitigate the glitchy frequency readout due to mis-counting by one clock cycle between successive zero crossings. I'm storing an array the size of the moving average window of frequency readouts at each clock cycle, and then taking the arithmetic mean over the window. By keeping a summing variable that updates itself each clock cycle, the actual moving average process isnt very intensive in terms of computational time. The array does take up some memory, but even if I perform the moving average over 1 second with 16384 double precision numbers stored in the array, its still only 130 kB so I don't think it is a concern. Some tests I've been doing while tuning the code suggest that with a moving average over 16384 samples (i.e. 1 second), I can eliminate glitches at the 1Hz level in the frequency readout for frequencies up to 5 kHz (generated digitally using an oscillator block). Some tuning still needs to be done, and the window could possibly be shortened. I also need to take a look at the systematic errors in this revised counting scheme, preferably with an analog source, but this is overall, I think, an improvement.

On a side note, I noticed some strange behaviour while running the cds average command - even though my signal had zero fluctuations, using z avg 10 -s C1:TST-FC_FREQUENCY_OUT gave me a standard deviation of ~1 kHz. I'm not sure what the problem is here, but all the calibration data I took in earlier trials were obtained using this so it would be useful to perform the calibration again. 

  11703   Tue Oct 20 16:27:04 2015 ericqUpdateVACvacuum VME machines rebooted

[ericq, Gautam, Steve]

Following roughly the same procedure as ELOG 11354, c1vac1 and c1vac2 were rebooted. The symptoms were identical to the situation in that ELOG; c1vac1 could be pinged and telneted to, but c1vac2 was totally unresponsive. 

The only change in the linked procedure was that we did not shut down the maglev. Since I unwittingly had it running for days without V4 open while Steve was away, we now know that it can handle shorter periods of time than that...

Upon reboot, many channels were readable again, unfortunately the channels for TP2 and TP3 are still blank. We were able to return to "Vacuum normal state," but because of unknowned communication problems with VM1's interlock, we can't open VM1 for the RGA. Instead we opened VM2 to expose the RGA to the main IFO volumn, but this isn't part of the "Normal" state definite, so things currently read "Undefined state".

  11702   Tue Oct 20 15:51:44 2015 ericqUpdateSUSMC2 F2P tuned

Using a modified version of Hang's deMod_deCoup scripts, I tuned the MC2 coil output matrix to minimize the appearance of POS drive in the SUSPIT signal at 28Hz. Up until now, there was no F2P compensation. This reduced the force to pitch coupling at 28Hz by 8dByes

Old: POS -> 1 x UL, 1 x UR, 1 x LL, 1x LR

New: POS -> 1.1054 x UL, 1.1054 x UR, 0.8946 x LL, 0.8946 LR

I checked the MCL spectrum before and after this change with OAF on, this did not spoil the feedforward length subtraction in any noticible way. 

The script lives in userapps/release/isc/c1/scripts/decoup, but I've symlinked it to /opt/rtcds/caltech/c1/scripts/decoup.


The script modification I made had to do with how the I and Q data is collected. Before, it was sporadically probing the I and Q FM output monitor EPICS values; I changed it to use the avg function of cdsutils, which calculates the mean and std from the 16kHz data and have seen it improve results by 1dB or so. I've been in touch with Jenne to propagate this to the sites. 

  11701   Tue Oct 20 11:24:29 2015 ericqHowToLSCHow to DRFPMI

Herein, I will describe the current settings and procedures used to achieve the DRFPMI lock, cobbled together from scripts, burts and such. 


Initial Alignment

  1. With arms POX/POY locked, run dither alignment servos. Set transmon QPD offsets here
  2. Restore "PRMI Carrier" configuration, run BS and PRM dither alignment servos simultaneously. (Note: this sacrifices some X arm alignment for better dark port alignment. In practice no appreciable loss of TRX is observed)
  3. Misalign PRM, align SRM and tune SRM alignment by eye while looking at AS camera. 
  4. Restore POX/POY arm lock, lock green to arms, check that powers are high enough and align if neccesary.

Initial Configuration

CARM, DARM

For CARM and DARM, the A channels are used for the ALS signals, whereas the B channels are used for blending the RF signals. 

ALS

  • BEATX and BEATY, I and Q channels: +0dB Whitening Gain, Whitening Filters ON
  • Green beatnotes somewhere between 20-80MHz, following sign convention of temperature slider UP makes beat freq go UP.  Check spectrum of PHASE_OUT_HZ vs references in ALS_outOfLoop_Ref.xml. The locking script automatically sets the correct phase tracker gain, so no need to adjust manually.
  • CARM_A = -1.0 x ALSX + 1.0 x ALSY, G=1.0
  • DARM_A = 1.0 x ALSX + 1.0 x ALSY, G=1.0

RF

  • CM Board: REFL11 I daugher board output -> IN1, IN1 Enabled, -32dB input gain, 0.0V offset, all boosts off, AO polarity positive, AO gain +0dB
  • MC Board: IN2 disabled, -32dB input gain
  • CM_SLOW: +0dB Whitening Gain, Whitening ON, LSC-CM_SLOW_GAIN = -5e-4 (Though, it would be good to reallocate this gain to the input matrix element)
  • CARM_B = 1.0 x CM_SLOW, FM4 FM10 ON, G=0 (FM4 = LP700 for AO crossover stability, FM10 = 120:5k for coupled cavity pole compensation)
  • AS55: +9dB Whitening Gain, Whitening filters manual, Demod angle -37.0
  • DARM_B = -1e-4 x AS55 Q, G=0

DRMI 3F

For the DRMI, the A channels are used for the 1F signals, whereas the B channels are used for the 3F signals. The settings for transitioning to 1F after locking the DRFPMI have not yet been determined. 

These settings are currently saved in the DRMI configurator, but the demod angles are set for DRFPMI lock, so the settings don't reliably work for misaligned arms. 

  • REFL33: +30dB Whitening Gain, Whitening filters trigger on DRMI lock, Demod angle: 136.0
  • REFL165: +24dB Whitening Gain, Whitening filters trigger on DRMI lock, Demod angle: -111.0
  • POP22: +15dB Whitening Gain, Whitening filters OFF, Demod angle: -114.0
  • AS110: +36dB Whitening Gain, Whitening filters OFF, Demod angle: -116.0
  • POPDC: +0dB Whitening Gain, Whitening filters OFF (used as a supplemental trigger signal when CARM and DARM are buzzing and POP22 fluctuates wildly)
  • MICH_B = 6.0 x REFL165Q, offset = 15.0
  • PRCL_B = 5.0 x REFL33I, offset = 45.0
  • SRCL_B = -0.6 x REFL165I + 0.24 x REFL33 I, offset=0

The REFL33 element in SRCL_B is to reduce the PRCL coupling, was found empirically by tuning the relative gains with the arms misaligned and looking at excitation line heights. The offsets were found by locking the DRMI on 1F signals with arms misaligned, and taking the average value of these 3F error signals.  

Servo filter configuration

The CARM and DARM ALS settings are largely scripted by scripts/ALS/Transition_IR_ALS.py, which takes you from arms POX/POY locked to CARM and DARM ALS locked. The DRMI settings are usually restored from the IFO_CONFIGURE screen. 

  • CARM: FM[1, 2, 3, 5, 6] , G=4.5, Trigger forced on, no FM triggers, output limit 8k
  • DARM: FM[1, 2, 3, 5, 6] , G=4.5, Trigger forced on, no FM triggers, output limit 8k
  • MICH: FM[4, 5], G= -0.03, Trigger POP22 I x 1.0 [50, 10], FM[2, 3, 7] triggered [50, 10], output limit 20k
  • PRCL: FM[4, 5], G= -0.003, Trigger POP22 I x 1.0 [50, 10], FM[1, 2, 8, 9] triggered [50, 10], output limit 8k
  • SRCL: FM[4, 5], G= -0.4, Trigger AS110 Q x 1.0 [500, 100], FM[2, 7, 9] triggered [500, 100], output limit 15k

Actuation Output matrix

  • MC2 = -1.0 x CARM
  • ETMX = -1.0 x DARM
  • ETMY = 1.0 x DARM
  • BS = 0.5 x MICH
  • PRM = 1.0 x PRCL - 0.2655 MICH
  • SRM = 1.0 x SRCL + 0.25 MICH (The mich compensation is very roughly estimated)

Locking Procedure

When arms are POX/POY locked, and the green beatnotes are appropriately configured, calling scripts/DRFPMI/carm_cm_up.sh initiates the following sequence of events:

  • Turn ON MC length feedforward and PRC angle feedforward
  • Set ALS phase tracker UGFs by looking at I and Q magnitudes
  • Set LSC-ALSX and LSC-ALSY offsets by averaging, ramp CARM+DARM gains up, XARM+YARM gains down, engage CARM+DARM boosts, now ALS locked
  • Move CARM away from resonance, offset = -4.0 (DRMI locks quicker on this side for whatever reason)
  • Restore PRM, SRM alignment. Set DRMI A FM gains to 0, B FM gains to 1.0. Enable LSC outputs for BS, PRM, SRM
  • When DRMI has locked, add POPDC trigger elements to DRMI signals and transition SRCL triggering to POP22I. NB: In the c1lsc model, the POPDC signal incident on the trigger matrix has an abs() operator applied to it first. 
    • MICH Trig = 1.0 x POP22 I + 0.5 x POPDC, [50, 10]
    • PRCL Trig = 1.0 x POP22 I + 0.5 x POPDC, [50, 10]
    • SRCL Trig = 10.0 x POP22 I + 5 x POPDC, [500, 100]
  • Reduce POX, POY whitening gains from their nominal +45dB to +0dB, so there aren't railing channels making noise in the whitening chassis and ADCs
  • DC couple ITM oplevs (average spot position, set FM offset, turn on DC boost filter, let settle)
  • With an 8 second ramp, reduce CARM offset to 0 counts. 
  • MANUALLY adjust CARM_A and DARM_A offsets to where CARM_B_IN and DARM_B_IN are seen to fluctuate symetrically around their zero crossing.
    • Note: Last week, this adjustment tended to be roughly the same from lock to lock, unlike the PRFPMI which generally didn't need much adjustment. Also, by jumping from CARM offset of -0.4 to 0.4, it could be seen that the zero crossing in  CARM_B aka CM_SLOW aka REFL11 had some offset, so CARM_B_OFFSET was set to 0.005, but this may change. 

When CARM and DARM are buzzing around true zero, powers maximized:

  • CARM and DARM FM1 (18,18:1,1 boosts) OFF
  • CARM_B_GAIN 0.0 -> 1.0, FM7 ON (20:0 boost)
  • DARM_B_GAIN 0.0 -> 0.015, FM7 ON (20:0 boost) 
  • MC servo board IN2 ENABLE, IN2 gain -32dB -> -16dB
  • Turn ALL MC2 violin filters OFF (smoothen out AO crossover)
  • If stable, CM board IN1 gain -32dB -> -10dB (This is the overall CARM gain, the arm powers stabilize within the last few dB of this transition)
  • CARM_A_GAIN 1.0 -> 0.7
  • CARM_A FM9 ON (LP1k), sleep, FM 1 ON (1:20 deboost), sleep, FM 2 ON (1:20 deboost), HOLD OUPUT, CARM now RF only
  • DARM_B_GAIN 0.015 -> 0.02, sleep, DARM_A_GAIN 1.0 -> 0.0 (This may not be the ideal final DARM_B gain, UGF hasn't been checked yet)

IFO is now RF only!

  • Turn on transmon QPD servos.
  • Adjust comm/diff QPD servo offsets to correct any problems evident on AS/REFL cameras. This usually brings powers from ~100-120 to ~130-140. 

This is as far as we've taken the DRFPMI so far, but the CARM bandwidth is still only at a few kHz. Based on PRFPMI locking, the next steps will be:

  • CM BOARD +12dB or so additional IN1 gain, more AO gain may be needed to get crossover to final position of ~100Hz
  • MC2 viollin filters back on
  • CM boost(s) on
  • AS55 whitening on
  • Transition DRMI to 1F
  11700   Mon Oct 19 16:20:52 2015 ericqUpdateLSCGreen beatnote couplers installed

Last Friday, I installed some RF couplers on the green BBPDs' outputs, and sent them over to Gautam's frequency divider module. At first I tried 20dB couplers, but it seemed like not enough power was reaching the dividers to produce a good output. I could only find one 10dB coupler, and I stuck that on the X BBPD. With that, I could see some real signals come into the digital system.

I don't think it should be a problem to leave the couplers there during other activities.

  11699   Mon Oct 19 16:16:01 2015 ericqUpdateCDSC1ALS crashes

Gautam was working on his digital frequency counter stuff when the c1als model crashed. I had trouble bringing it back until I realized that, for reasons unknown to me, the safe.snap file that the model looks for at boot had been deleted. (This file lives in /target/c1als/c1alsepics/burt). I copied over this morning's version from Chiara's local backup. 

At the sites, these files are under version control in the userapps svn repository, presumably symlinked into the target directory. We should definitely do something along these lines. 

  11698   Mon Oct 19 15:23:22 2015 ericqUpdateLSCLonger DRFPMI lock

Here is a longer lock, about 100 seconds RF only, from later that same night. The in-loop CARM and DARM error signals have the order of magnitude of 1nm per count. 

From ~-150 to -103, we were fine tuning the ALS offsets to try and get close to the real CARM/DARM zero points then blending the RF CARM signal. 

At -100, the CARM bandwidth increases to a few kHz and stabilizes the arm powers. By -81, the error signals are all RF. At -70, I turned on the transmon QPD servos, which brought the power up a bit. 

If I recall correctly, lock was lost because I put waaaay too big of an excitation on DARM with the goal of running its UGF servo for a bit. The number I entered was appropriate for ALS, but most certainly too huge for AS55...

  11697   Mon Oct 19 11:20:34 2015 gautamUpdateVACRGA scan reset

Steve pointed out that in the aftermath of the Nitrogen running out a couple of times last week, the RGA had shut itself off thinking that there was a leak and so it was not performing the scheduled scans once a day. So the data files from the scheduled scans were empty in the /opt/rtcds/caltech/c1/scripts/RGA/logs directory. The wiki page for getting it up and running again is up-to-date, but the script RGAset.py did not exist on the c0rga machine, which the RGA is communicating with via serial port. I copied over the script RGAset.py from rossa to c0rga and ran the script on that machine - but the error flags it returned were not all 0 (indicating some error according to the manual) - so I edited the script to send just the initialize command ('IN0') and commented out the other commands, after which I got error flags which were all 0. After this, I ran a manual scan using 'RGAlogger.py', and it appears that the RGA is now able to take scans again - I'm attaching a plot of the scan results. We've saved this scan as a reference to compare against after a few days. 

Attachment 1: RGAscan_151019.png
RGAscan_151019.png
  11696   Sat Oct 17 18:55:07 2015 ranaUpdateLSCDRFPMI Locked for 20 sec

smiley in addition to Koji's words I feel like we should also thank those who made small but positive contributions. Its hard not to notice that this locking only happened after the new StripTool PEM colors were implemented...

From the times series plot I guess that the fuzz of the in-loop DARM is 1 pm RMS (based on memory). This means that the ALS was holding the DARM at 10 pm from the RF resonances.

There is no significant shift in the DRMI error signals, so new weird CARM effect. Would be interesting to see what the 1f signals do in the last 60 seconds before RF lock.

For documentation, perhaps Gautam can post the loop gain measurements of the 5 loops on top of the Bode plots of the loop models.

  11695   Fri Oct 16 18:27:52 2015 SteveUpdateVAC vacuum normal condition

Vacuum normal configuration with VM1-closed, VM2-open valve positions. Power load normal 24V 0.2A

Maglev rotation 560 Hz at room temp body temp.

"NO COMM" error message on medm screen. Gauge controller pressures are read able.

All vac comp LEDs are green. We have to reboot on Monday to enable communication.

 

Attachment 1: oct16Fpm2015.png
oct16Fpm2015.png
  11694   Thu Oct 15 14:39:58 2015 ericqUpdateComputer Scripts / Programsnodus web apache simlinks too soft
Quote:

None of the links here seem to work. I forgot what the story is with our special apache redirect frown

https://wiki-40m.ligo.caltech.edu/Core_Optics

The story is: we currently don't expose the whole /users/public_html folder. Instead, we are symlinking the folders from public_html to /export/home/ on nodus, which is where apache looks for things

So, I fixed the links on the Core Optics page by running:

controls@nodus|~ > ln -sfn /users/public_html/40m_phasemap /export/home/

  11693   Thu Oct 15 10:59:12 2015 KojiUpdateLSCDRFPMI Locked for 20 sec

Great job!
Many thanks Eric, Gautam, and all the current and past colleagues
for your tremendous contributions to bring the 40m to this achievement.

  11692   Thu Oct 15 04:14:14 2015 ericqUpdateLSCDRFPMI Locked for 20 sec

Fast ALS was still a problem tonight. I don't think high frequency ALS noise saturating the PC drive is the issue; I put two 10k poles before the CM board (shooting for just 2-3kHz bandwidth), and the PC drive levels would be stable and low up until the lockloss, which was always conincident with a step in the AO gain.

After working with that for a few hours, we turned back to our more standard locking attempts. First, we dither aligned the PRMI, and then centered the REFL beam on REFL11. It's hard to say for certain, but we may have been a little close to the edge of the PD. The only other thing that differed from Monday's attempts was using 6dB less AO gain when trying the up the overall gain. 

The script now reliably breaks through to stable high powers, we had a handful of pure-RF locks tonight. The digital DARM gain needs tuning, and the CARM bandwidth still isn't at its final state, but these are very tractable. Off the top of my head, the way forward now includes:

  • Set proper final DARM loop shape
  • Set final CARM loop shape
  • Take full sensing matrix
  • Make 1F handoff
  • Set up the CAL model to produce (at least roughly) calibrated spectra
  • measure noise couplings and other fun stuff

Unrelated: I feel that the PRC angular FF may have deteriorated a bit. I'm leaving the PRC locked on carrier to collect data for wiener filter recalculation. 

  11691   Thu Oct 15 03:08:57 2015 ericqUpdateLSCDRFPMI Locked for 20 sec

[ericq, Gautam]

For real this time.

Attachment 1: DRFPMI_locked.pdf
DRFPMI_locked.pdf
  11690   Wed Oct 14 17:40:50 2015 gautamUpdateCDSFrequency divider box - further tests

Summary:

I carried out some further diagnostics and found some ways in which I could optimize the zero-crossing-counting algorithm, such that the error in the measured frequency is now entirely within the expected range (due to a +-1 clock cycle error in the counting). We can now determine frequencies up to ~60 MHz with less than 1 MHz systematic error and <10 kHz statistical error (fluctuations after the 20 Hz lowpass). This should be sufficient for slow control of the end-laser temperatures.

Details: 

The conclusion from my earleir tests was that there was possibly an improvement that could be made to setting the thresholds for the Schmitt trigger stage in the model. In order to investigate this, I wanted to have a look at the 64K sampled raw input to the ADCs. Yesterday Eric helped me edit the appropriate .par file for viewing these channels for c1x03, and for an input frequency of 70MHz (after division, ~4.3 kHz square wave), the signal looked as expected (top left plot, attachment #1). This prompted me to check the counting algorithm again with the help of various test points I had setup within the model. I found that there was a tendency to under-count the number of clock-cycles between zero-crossings by more than 1 clock cycle, due to the way my code was organized. I fixed this and found that the performance improved dramatically, compared to my previous trials. With the revised counting algortihm, there was at most a +-1 clock cycle error in the counting, and the systematic error between the measured and requested RF frequencies is now completely accounted for taking this consideration into account. The origin of this residual error can be understood by looking at the top right plot in Attachment #1 - presumably because of the effects of some downsampling filter, the input signal to the Schmitt trigger isnt a clean square wave (even at 4kHz) - specifically, the time spent in the LOW and HIGH states of the Schmitt trigger can vary between successive zero crossings because of the shape of the input waveform. As a result, there can be a +-1 clock cycle error in the counting process. Attachment #2 shows this - the red and blue lines envelope the measured frequency for the whole range investigated: 10-70MHz. Attachment #3 shows the systematic error as a function of the requested frequency.

If there was some way to bypass the downsampling filter, perhaps the high-frequency performance could be improved a little. 

Attachment 1: time_series_input_signals.pdf
time_series_input_signals.pdf
Attachment 2: calibration_20151012.pdf
calibration_20151012.pdf
Attachment 3: systematics_20151012.pdf
systematics_20151012.pdf
  11689   Wed Oct 14 16:53:22 2015 KojiUpdateGeneralNon inverting buffer for SR560

Eric needed a buffer to drive low input impedance (~130Ohm) of his pomona box, I quickly made a non-iverting buffer with G=+10. The DC power is obtained from the back of SR560. It uses 1.02K and 9.09K
to have the gain of ~10. The chip is OP27. In fact this limits the output swing to be +/-5V for the load resistance of 130Ohm. Eric thinks this is enough. If we need more, we need to swap the chip.

As SR560s tend to saturate too quickly, it would be very useful to have this kind of kit in all the labs
once it is packed in a box.

Attachment 1: IMG_20151014_145608547.jpg
IMG_20151014_145608547.jpg
Attachment 2: IMG_20151014_145548751.jpg
IMG_20151014_145548751.jpg
  11688   Wed Oct 14 15:59:06 2015 ranaUpdateComputer Scripts / Programsnodus web apache simlinks too soft

None of the links here seem to work. I forgot what the story is with our special apache redirect frown

https://wiki-40m.ligo.caltech.edu/Core_Optics

  11687   Tue Oct 13 17:04:54 2015 ericqUpdateCDSCDS things

After some discussion at last week's 40m meeting, I increased the frequency of daqd trying to write out minute trends from hourly to every two hours.

This has eliminated the hourly crashes. daqd still crashes sometimes, but only a few times per day. yes

However, looking at the oplev summary pages that actually use the minute trends, it looks like they're only sporadically getting succesfully written out. no


Also, I was having a lot of problems with the frontends' EPICS processes dying when I would try to update the SDF table. I rebuilt all of the frontends with RCG 2.9.6, which differs from the 2.9.4 that we had been running by SDF bugfixes and an RMS calculation bugfix. The SDF procedures are much more stable now. 

I have not yet discovered anything broken by this chage, and the tests I made for the last upgrade were all fine; last weeks tiny DRFPMI lock was achieved after this change. 

  11686   Tue Oct 13 16:28:21 2015 ericqUpdateLSCFast ALS pomona

I've made a cascaded passive 2-pole pomona box for fast ALS use, using LISO to check that it'll give the right shape when hooked up to the CM board's input stage. 

First stage is a 133Ohm + 10uF cap for ~120Hz LP, second is 1.15kOhm + 47nF cap for ~3.8kHz LP. The DC gain is ~0.75, which is much better than what I was doing before. The second stage would normally make a 2.9kHz LPF on its own, but the loading of the input stage moves the corner up. 

It seems the 133 Ohm resistor is a reasonable load on the output AD829 of the ALS demod board (short-circuit output current of 32mA and a series output resistor of 499Ohm). To be able to use the digitized ALSX I and the lowpassed analog version simultaneously, I had to buffer the signal with a SR560 before the pomona box, otherwise the signals looked distorted. This isn't a good long-term solution. Maybe I can used the further-buffered differential output to drive the LPF+CM board. 

The LISO files used to model the filter and CM board input stage, and fit the pole frequencies are attached. 

I made some attempts to get the AO path going today, but I suspect this daytime noise is just too much; the PC drive seems too irritable

Attachment 1: liso_lp.zip
Attachment 2: 2LPfit.pdf
2LPfit.pdf
  11685   Tue Oct 13 05:48:39 2015 ericqUpdateLSC:/

[ericq, Gautam]

Despite our best efforts, the grappa remains out of reach: the DRFPMI was not locked tonight. 

We spent a fair amount of time with the AUX X laser, as it was glitching madly again.

DRMI was finicky until I found some more reliable triggering settings; namely aquiring with AS110Q, but after that transitioning the trigger to the same POP22+POPDC combo as PRCL and MICH. With this in place, the DRMI lock seems really indefinite no matter what CARM seems to do; or at least, I always lost lock due to CARM shenanigans after this. 

The most frustrating part was the fact that I just couldn't cross over the AO path stably. It never "clicked" into high circulating power as it normally does (either in PRFPMI, or how it was last week). Various crossover filters and tweaks were attempted to no avail. Morning traffic starts soon, so we're calling it a night. 

  11684   Mon Oct 12 17:04:02 2015 gautamUpdateCDSFrequency divider box - further tests

I carried out some more tests on the digital frequency counting system today, mainly to see if the actual performance mirrors the expected systematic errors I had calculated here

Setup and measurement details:

I used the Fluke 6061A RF signal generator to output an RF signal at various frequencies, one at a time, between 10 and 70 MHz. I split the signal (at -15 dBm) into two parts, one for the X-channel and one for the Y-channel using a mini-circuits splitter. I then looked at the input signal using testpoints I had set up within the model, to decide what thresholds to set for the Scmitt trigger. Finally, I averaged the outputs of the X and Y channels using z avg -s 10 C1:ALS-FC_X_FREQUENCY_OUT and also looked at the standard deviation as a measure of the fluctuations in the output (these averages were taken after a low-pass filter stage with two poles at 20Hz, chosen arbitrarily).

Results:

  • Attachment #1 shows a plot of the measured RF frequency as a function of the frequency set on the Fluke 6061A. The errorbars on this plot are the standard deviations mentioned above. 
  • Attachment #2 shows a plot of the systematic error (mean measured value - expected value) for the two channels. It is consistent with the predictions of Attachments #3 and #4 in elog 11628 (although I need to change the plots there to a frequency-frequency comparison). This error is due to the inherent limitations of frequency counting using zero crossings, I can't think of a way to get around this).
  • I found that a lower threshold of 1800 and an upper threshold of 2200 worked well over this range of frequencies (the output of the Wenzel dividers goes between 0V and 2.5V, and the "zero" level for the digitized signal corresponds to ~2000, as determined by looking at a dataviewer plot of a tetspoint I had set up in my model). Koji suggested taking a look at the raw ADC input signal sampled at 64 kHz but this is not available for c1x03, the machine that c1als runs on. 

 

 

Attachment 1: calibration.pdf
calibration.pdf
Attachment 2: systematics.pdf
systematics.pdf
  11683   Fri Oct 9 19:54:58 2015 gautamUpdateCDSFrequency divider box - installation in 1X2 rack

The new ZKL-1R5 RF amplifier that Steve ordered arrived yesterday. I installed this in the frequency divider box and did a quick check using the Fluke RF signal generator and an oscilloscope to verify that both the X and Y paths were working. 

I've now installed the box in the 1X2 rack where the olf "RF amplifiers for ALS and FOL" box used to sit (I swapped that out as I needed the L brackets on that chassis to mount mine, see Attachment #1 for the new layout). The power cable that used to power the old chassis was available, but the connector was of the wrong gender, so I had to switch this out. After verifying that I was getting the correct voltage (+15V), I connected it to the chassis.

I then did a quick check with the Fluke generator to make sure that all was working as expected - Eric had set up some ADC channels for me earlier today in the C1ALS model, and I copied over my frequency counting module from C1TST into C1ALS, and recompiled the model. The RF generator was set to generate a 25MHz signal at -20dBm, which I then split using an RF power splitter between the X and Y arms. I then checked the output using dataviewer - I recovered an output frequency of ~27.64 MHz with a jitter of ~0.02 MHz with a 20Hz low-pass filter in place (see Attachment #2), which looks consistent with the systematic error inherent in the zero-crossing counting algorithm and random fluctuations I had observed in my earlier trials, discussed here. But a more systematic investigation needs to be carried out in this regard. The interfacing between the hardware and software seems to be working alright though. I've left the RF generator near the 1x2 rack for now, though its powered off. 

The mode cleaner unlocked quite a few times while I was working but looks stable now. 

 

Attachment 1: IMG_0027.JPG
IMG_0027.JPG
Attachment 2: time_seris_25MHz.pdf
time_seris_25MHz.pdf
  11682   Fri Oct 9 16:43:50 2015 ericqUpdateIOOWeird IMC behavior

A few minutes ago, Gautam and I were poking around the IOO rack, looking at where he should power his frequency divider box, and what ADC innputs to use. 

Looking at the mode cleaner signals, it looks like we may have jostled something in a good way. Weird. 

  11681   Fri Oct 9 16:23:25 2015 ericqUpdateLSCALS plant shape

Ah, I understand it now! Since the additive offset path keeps the post-cavity frequency TF flat, the pre-cavity frequency must grow above the cavity pole, which is why ALS sees a zero. 

Ok, so this means we want to apply two lowpasses to the ALS signal for use as fast CARM control, if we want it to be capable of scalar blending with REFL11: one at ~120Hz to imitate the CARM coupled cavity pole present in REFL11, and one at ~3.8kHz to undo the "IMC cavity zero" present in ALS. 

At this point, I'm starting to prefer an active circuit to do this lowpassing; using LISO to check designs for two cascaded passive LPFs it looks like the ALS signal would have to be attenuated by a factor of ~20 at DC if we don't use resistors smaller than 1k, given the low input impedence of the CM board. 

  11680   Fri Oct 9 14:50:18 2015 KojiUpdateLSCALS plant shape

ALS is the comparison of the PSL laser freq vs the end laser freq that is locked to the arm cavity resonant freq

On the other hand, the AS55 PDH is the comparison of the PSL laser freq after the IMC vs the arm cavity resonant freq. Here the PDH signal involves the arm cavity pole.

In total you observe the difference by the IMC cav pole + the arm cav pole.

  11679   Fri Oct 9 13:31:21 2015 ericqUpdateLSCALS plant shape

To get a better look at how to do fast ALS, I took some "Plant TF" measurements of the X arm. 

Specifically, in single arm POX lock and the both Y TMs misaligned, I used the SR785 to inject into EXC B of the common mode board with the CM fast output gain and IMC IN2 gain both at 0dB, and looked at the transfer function of that excitation into the analog ALSX I and AS55 Q out-of-loop signals. (ALSX I tuned to a zero crossing via the delay line box as usual.)

My expectation was to see them only differ by the IR single arm cavity pole, which should be around 8-9kHz ( FSR/450 = 3.9MHz/450 ~ 8.6kHz). The green cavity pole at ~18k shouldn't show up since we're not touching the green light, and the IMC pole at ~3.8kHz shouldn't show up since this is well within the IMC loop bandwidth and we're actuating on its error point.  

Instead, I see them differ by a double pole at 4.3kHz. (or zero, if you look at it the reciprocal way). Vectfit actually fits them as a slightly complex pair, with a Q of 0.53/ I imagine that the wiggles are due to the digital control loop.

My question is: why is there a double zero here? Where has my reasoning led me astray?

 

Attachment 1: xarm_plantTFs.pdf
xarm_plantTFs.pdf
  11678   Fri Oct 9 11:41:09 2015 ericqUpdateVACN2 Pressure fell

At 10:02AM, the N2 Pressure fell below 60 PSI. The watch script saw this happen, but I did not recieve the email it is supposed to send frown

C1:Vac-P1_pressure reads 7e-4, which is the same as it has for the past ~2 days, so the V1 interlock worked fine. 

I've put some fresh N2 into the system, and Bob will pop in over the weekend to check it. I'll stay on top of it until Steve gets back. 

After consulting ELOGs and the 40m wiki, I reasoned it was ok to open the V1 to reconnect the turbo pump to the main IFO volume and VM1 to reconnect the RGA, and have now done so. 

  11677   Fri Oct 9 11:24:06 2015 JenneUpdateLSCDRFPMI Progress

I hope the grappa was already cold, and ready to drink! 

  11676   Fri Oct 9 09:22:38 2015 ericqUpdateLSCDRFPMI Progress

Look upon this three second lock, ye Mighty, and rejoice!

Attachment 1: oct8_allRF.pdf
oct8_allRF.pdf
  11675   Thu Oct 8 21:35:49 2015 ranaUpdateLSCDRFPMI Progress

Give us a lockloss or other kind of time series plot so we can bask in the glory.

  11674   Thu Oct 8 16:48:23 2015 KojiUpdateLSCDRFPMI Progress

Awesome

  11673   Thu Oct 8 14:14:50 2015 ericqUpdateLSCDRFPMI Progress
Quote:

Please clarify: I wonder if you were at the zero offset for CARM and DARM or not. 

Yes, this was at the full DRFPMI resonance.

  11672   Thu Oct 8 13:13:20 2015 KojiUpdateLSCDRFPMI Progress

Please clarify: I wonder if you were at the zero offset for CARM and DARM or not. I am 25% excited right now.

  11671   Thu Oct 8 04:48:50 2015 ericqUpdateLSCDRFPMI Progress

Progress was made. CARM was stably locked on RF only. DARM was RF only for a few moments before I typed in a wrong number...

A change was made to the LSC model's triggering section to make the DRMI hold more reliably at zero CARM offset. Namely, the POPDC signal now has its absolute value taken before the trigger matrix. Even unwhitened, it occaisionally would somehow go negative enough to break the DRMI trigger.

AUX X laser was acting up again. As before, tweaking laser current is the temporary fix.

  11670   Tue Oct 6 16:56:40 2015 gautamUpdateGeneralFOL fiber box revamp

[gautam, ericq]

We had a look at the IR beat (PSL+Xarm) today using the new FOL fiber box, and compared it to the green beat signal for the same combination. We first switched out the green Y beat input into the RF amplifiers on the PSL table with the PSL+Xarm IR beat input (so in all the plots, the BEATY channels really correspond to the IR beat for PSL+X). The IR and green beat notes were found without much difficulty, and we compared the beat signal PSDs for the green and IR signals (see Attachment #1 - arms were locked to green and the X slow control was turned on). The pink trace (labeled REF1) corresponds to the green beat signal, and was in good agreement with an earlier reference trace Eric had saved for the same signal. The teal trace (labeled REF0) corresponds to the the IR beat signal monitored simultaneously. 

We then went back to the PSL table to check the amplitude of the signal from the broadband fiber PDs using the Agilent network analyzer. An initial measurement yielded a beat note (@~50MHz) at ~-22dbm (17mV rms). We figured that by bypassing the 90-10 splitter in this path, we could get a stronger signal. But after switching out the fiber connections we found that the signal amplitude had fallen to ~-27dbm (10mV rms). As per my earlier measurements here, we expect ~600uW of light on the PD, and a quick calculation suggested the signal should be more like 60mV, so we used the fiber power meter to check the power levels after each of the couplers again. We then found that the fiber connector on the front panel of the box for the PSL input wasnt ideal (the laser power after the first 50-50 coupler was only ~250 uW, though the input was ~1.2  mW). The power after the first coupler also fluctuated unpredictably (<100 uW to 350 uW) in response to slightly tightening/loosening the fiber connections on the front panel. I then switched the PSL input to one of the two unused fiber connectors on the front panel (meant for the 10% of the beat signal for the DC readout), and found that this input behaved much better, with ~450 uW of power available after the first 50-50 coupler. The power going into the beat PD was also measured to be ~550uW, closer to what was expected. The beat signal peak now was ~-14dbm (~30mV rms).

We then once again repeated the comparison between green and IR beat signals - but while in the control room, I noticed that the beat signal amplitude on the network analyzer in the control room was fluctuating by nearly 1.5 divisions on the vertical scale - not sure what the reason for this is. A look at the PSD of the IR beat with higher power incident on the PD was also not encouraging (see blue trace in Attachment #1), it seems to have gotten worse in the 10-30 Hz range. We also looked at the coherence between the beat spectrum and the beat note amplitude in order to look for any linear coupling between the two, but from Attachment #2, we cannot explain the disparity between the green and IR beat spectra. This warrants further investigation.

Everything on the PSL table has now been restored to the configurations before these investigations (i.e. the Y+PSL green beat cable has been reconnected to the RF amplifier, and both green beat PDs have been powered back ON. The fiber PDs are powered OFF) 

Attachment 1: 20151006_Xbeat_psd.pdf
20151006_Xbeat_psd.pdf
Attachment 2: 20151006_Xbeat_coherence.pdf
20151006_Xbeat_coherence.pdf
  11669   Tue Oct 6 03:30:17 2015 ericqUpdateLSCDRFPMI Progress

[ericq, Gautam]

Highlight of the night: the DRFPMI was held at arm powers > 110 for 20 seconds. ALS feedback was still running though, but so was some nonzero REFL11 AO path action.

In short, time was spent finding the right FM trigger settings to keep the DRMI locked while CARM is fluctuating through resonance, what CARM offset to acquire DRMI lock at, order of operations of turning on AO / turning up overall CARM gain, etc. 

Sadly, for the past hour or so, the DRMI has refused to stay locked for more than ~20 seconds, so I haven't been able to push things much further. This is a shame, since I'm very nearly at the equivalent point in the PRFPMI locking script where the ALS control is turned off completely. 

  11668   Mon Oct 5 16:41:22 2015 SteveUpdateSUSETMY OL laser replaced

This JDSU 1103P laser, sn P892324 lived for 2 years. It's power output is 0.05 mW now

It was replaced with brand new JDSU 1103P,  sn P919645, Mfg date 12/2014 with 2.75 mW output.

There is 0.14 mW  light returning to the qpd = 7,250 counts without AR 632 lenses

  11667   Mon Oct 5 11:25:21 2015 ericqUpdateSUSETMY OL laser dead

Gautam alerted me that the Y arm looked like it was being dithered, even though the ASS was turned off. I found that the ETMY OL signals were garbage, leading to the servos flipping back and forth between their rails. 

We went out to the ETMY table, and found the HeNe laser to be emitting a paltry <0.5mW; the OL QPD could not register the puny beam incident on it.

Here is the last 30 days of OL_SUM:

Steve will replace the laser this afternoon. 

  11666   Mon Oct 5 10:11:35 2015 SteveUpdateVACRGA scan pd78 day 386

RGA background scan.

The IFO is closed off from RGA with VM1

CC4 ( and CC1)  is still flaky and it's interlock closes VM1

 

Attachment 1: RGA_background.png
RGA_background.png
  11665   Sun Oct 4 14:32:49 2015 jamieConfigurationCDSCSD network test complete

Here's an example of the glitches we've been seeing, as seen in the StripTool trace of the front end oscillator:

You can clearly see the glitch at around T = -18.  Obviously during non-glitch times the sine wave is nice and cleanish (there are still the very small discretisation from the EPICS sample times).

ELOG V3.1.3-