We looked into the PLL servo. First we checked the temperature feedback signals to the laser. They did seem ok, although the green had a 1mV offset (although not being written to it). We disconnected the green temp feedback.
The IR laser crystal temperature feedback was ok, but only after we managed to reset it to zero. Even the EPICS display was not showing all the digits (we got an intergrator gain of 1e-6). The EPICS screen displays voltage, which is good to know.
We had to adjust the temprature on the laser to find the beatnote, it was set back to 42.1 deg C. The knob on the front panel is very 'coarse', so the beatnote was within 10 MHz from the nominal 39.7 MHz. We engaged the temperature servo and we saw the beatnote move towards the 39.7 MHz. The Phase-Frequency Discriminator has a flat gain when the beatnote is far away from the LO frequency (39.7 MHz). Although not a problem, with low gain you do wait for it:) You can speed it up by engaging the CMB-A servo, which feedback to the PZT. Matter of fact, the temp signal is a plain copy of the PZT signal, which goes through the Beckhoff system and has it sown little servo.
We looked on an oscilloscope at the temperature feedback signal. There are a few ripples in the signal at ~1 micro second, ~5 microseconds and ~2 milli seconds. I think we should add an analog 10 Hz low pass filter at the output to remove these. The temperature feedback has a bandwidth of up ~0.5 Hz anyway.
Looking at the PZT feedback signal. It has ~1.5Vpp 'oscillations' with a ~10s period appearing and then fading away. This is of course the 'equivalent' noise the laser tries to follow. The PZT frequency to volts conversion is ~3 MHz/V, so that indicates that the laser frequency fluctuates by ~4.5 MHz!
Looking a the I-mon from the Phase-Freq Discriminator it is flat when locked (and around the 39.7 MHz). When further away the signal looks like 'pulse-widht-modulated' with an average voltage which correspond to how far away the beatnote is and is expected. I don't know how far the beatnote needs to drift, at which point the frequency discriminator takes over from the phase discriminator. All-in-all the I-mon doesn't seem to be bad or noisy.
We looked into the PLL which seemed to be ok (see other entry 3601). We didn't pay much attention to the RefCav yet, as we want to to make the cavity lock again. To make this happen we had to reset the ETMY HEPI, lucky Fabrice was here to help. The output on ISC BLEND_RZ was off. All is well.
We have fringes again, and the REFL_PWR_MON seems to be at its previous healthy ~11000 counts level. When engaging the cavity locking (CMB-B), it seemed to be ok until is starts the oscillation at 10-20 sec period. I turned the first boost filter off which didn't seem to help much. The VCO frequency drifts upto 39.78 MHz (from 39.603 MHz nominal). It almost looks like there is a sign wrong, it locks, fluctuates around 0 then creeps to the -10V limit. When you look at the VCO frequency it keep slowly climbing. At the same time the cavity power drops. Hmm, maybe still something in the PLL servo is not right.
We have two new indicator on the OAT screen, 'RefCav Trans (V)' and 'Beatnote at (Hz)'. The first one is nominal at 1.1 V (has a green box when above 0.8V, and a red box when <0.4V), and indicates if the RefCav is locked. The Beatnote shows the VCO frequency in Hz, nominal at 39.603 MHz.
I left the cavity unlocked, but the PLL engaged.
A good .snap time is Wed July 25 2012, 20:00h (and half hour from now).
The H2 dust monitor alarm went off. Not sure what button to press, so I pressed silince for one hour ...
At 7:08 the tumble weeds are being gathered.
J. Kissel, T. Vo Now that the optical lever signal chains are functional, it's straight forward to include Thomas' calibration into the signal chain and grab a spectra. Attached are the results for ETMY and ITMY. I'm not sure if I believe the amplitude of the results though. Even though Fabrice has been making excellent progress with H2 ISI ITMY, I don't think we're down to the sub- nrad / rtHz at 0.5 Hz. We'll go through the calibration more thoroughly tomorrow, and see where I've screwed up. Anyways, for posterity, my calibration is as follows (which, although Thomas only has official calibration for ETMY, I used the same calibration for both assuming the signal chains and lever arms are roughly the same): DOF ADC Gain Oplev Calib. (order of mag.) Pitch: 40/2^16 [V/ct] * 1666 [urad/V] * 1e-6 [rad/urad] = 1.0168e-6 [rad/ct] Yaw: 40/2^16 [v/ct] * 1727 [urad/V] * 1e-6 [rad/urad] = 1.0541e-6 [rad/ct]
Blend Filters were refined on ITMY. The current state is: 750 mHz in Stage 1 RX and RY 250 mHz in Stage 2 All dofs, and Stage 1 X, Z, RZ 100 mHz on Stage 1 Y The plot attached shows the latest isolation results (Red is Damped, Blue is Isolated). We are converging toward a configuration that we should be able to copy/paste on other units. Otherwise, I was having to turn the loops in the low blend configuration. The "boost" filters were making glitches in the actuators output, tripping the watch dogs. I modified the output compensation filters to filter out the glitches. The turn on/off process is now smooth and do not trip the watchdogs anymore.
J. Kissel, T. Vo, R. McCarthy After installing the new QPD.mdl library part and getting the channels reflected onto the the QUAD MEDM screens, we found nonsense coming out after the normalisation step of the signal processing. Here, "nonsense" is defined as Input to the normalization: Pin = -2400 Yin = -2900 SUM = -10700 Output of the normalization: Pout = Pin / SUM = 2.4e+9 = nonsense Yout = Yin / SUM = 2.9e+9 = nonsense Given that this library part is working quite well for the rest of the LIGO world that's using it, it implies that there's something screwy going on with our signal chain. We then tried turning off the signal input and inserting offsets with small (off order 1), known values to provide simple tests to see if the normalization was functional. With just offsets, the signals make sense. DAH! After a little more head scratching and a few more rounds of guess and check, I realized the difference between the input signals and the offsets I was trying: the raw input signals are negative (which Thomas informs me is expected from the electronics). *ACHOO!* Inverting the sign in the SEG (input filters), all works great. My guess is that the RCG Saturation Part, which has its limits set to [1e-6,1e12] treats the negative numbers as the lower limit, and divides the signal by 1e-6. (Hence 2400 / 2.4e9 = 1e-6). An analog signal chain red-herring that led to some interesting discoveries: We'd suspected initially that there was some high-frequency content saturating the ADC (that made it not visible in EPICS variables). A spectra of the raw segment channels, up to 7 kHz, later revealed no such features. However, while we still suspected this was true, we dove into the whitening chassis just to better understand the signal chain (since it's the only thing between the QPD and the AA chassis). We discovered that, though originally designed to have one, the ISC whitening board (D1001530), which is internal to the Oplev Whitening Chassis (D1100013), did NOT have its daughter board that fixes the state of the typically-digitally-controlled, switchable-state filter board. Mohana had some extra, and will ship some over night. Once those are in place, we can play around with the whitening and gain to find a good state in which we can leave it.
Attached are plots of dust counts > .5 microns in particles per cubic foot.
Today from ~ 3:00 pm to 5:20 pm local time I excited the TOP stage of the Y arm suspensions (first ITMY, then later ETMY) in order to gather peak height data to help with diagonalizing the OSEM sensor readbacks. Power spectra were recorded with damping at the top stage turned OFF, while an excitation of white noise was simultaneously injected into all 6 degrees of freedom of the top stage. The XML templates are saved in the suspension directories: /ligo/svncommon/SusSVN/sus/trunk/QUAD/H2/ETMY/SAGL2/2012-07-25_top_actuation_ETMY_4times_power.xml /ligo/svncommon/SusSVN/sus/trunk/QUAD/H2/ITMY/SAGL2/2012-07-25_top_actuation_test.xml I also tried to drive the L2 stage of ITMY with damping OFF at the top stage, but failed to get any coherence in this power spectrum measurement.
Dave and I finished installing the models, and MEDM screens, for HAM3.
I built the HAM3 testing folder arborescence, filled HAM3 matrices and started trying the scripts we will use for the in-chamber testing.
In-field cables arrived today. Richard and his crew started installing them.
HAM3 balancing is planned tomorrow. This balancing will be performed with the BNC outpus of the CPSs' ADE boxes.
Various activities - rebooting of SUS models for QUADs in the morning, another in the afternoon - Thomas Vo to End-Y station - noisy work in the LVEA from ~1:00PM - 3:00PM - leak detecting work in the Optics Lab
After creek baking and reassembling H1-MC3, the Lower Blade break off heights did not come back to their pre creek bake values. There was a greater than the 0.5mm vertical tolerance between the four blade tips. We tweaked several suspension adjustments but could not bring the tips into compliance. The best we could get was a maximum of 0.75mm height difference between the blade break offs. All other parameters are well within spec. We ran transfer functions on the M1 level to see if the suspension would perform correctly with the Lower Blade heights a bit off. Jeff K., Andres R., and I looked over the plots and compared H1-MC3 with several other suspensions. H1-MC3 compares favorably with the other HSTS suspensions. It was decided to install the AOSEMs and start Phase 1b testing.
We continue having problems with Tripleteststand loosing communications with the IO Chassis. Tripleteststand did not recover after power down power up reset. Richard M. replaced cards in the IO Chassis and Jim B. restarted IOP, the x1sushxts27 model, and Burt restored the system from 20120622-x1sushxts27_PR2.snap. The Tripleteststand is up and appears to be running normally.
During the QUAD models updates last week, the /opt/rtcds/userapps/release/sus/common/src/ corner of the userapps repository had not been updated, so we didn't receive Joe Betzwieser's PUM stage fix to the /opt/rtcds/userapps/release/sus/common/src/CD_STATE_MACHINE.c bit of c-code that controls the analog and digital filtering interaction between the coil drivers. In addition to updating that corner before the recompile, I also added two EPICs monitor blocks between the MTRX and normalization steps in the /opt/rtcds/userapps/release/isc/common/models/QPD.mdl library part. This change has been committed to the trunk. Finally, I made sure to capture the current status of the QUADs (as the ISC team left while trying to lock the cavity this morning), in /opt/rtcds/userapps/release/sus/h2/burtfiles/itmy/h2susitmy_H2OAT_110725.snap /opt/rtcds/userapps/release/sus/h2/burtfiles/etmy/h2susetmy_H2OAT_110725.snap and then turned off the damping loops and master switches, left the latest P and Y offsets the offsets in place, and captured new safe.snap files, which are used here: /opt/rtcds/userapps/release/sus/h2/burtfiles/itmy/h2susitmy_H2OAT_110725.snap /opt/rtcds/userapps/release/sus/h2/burtfiles/etmy/h2susetmy_H2OAT_110725.snap but are actually symbolic links to /opt/rtcds/userapps/release/sus/h2/burtfiles/etmy/h2susetmy_safe.snap /opt/rtcds/userapps/release/sus/h2/burtfiles/itmy/h2susitmy_safe.snap With these two changes in place, I recompiled, reinstalled, restarted, AND restored. The new epics variables are now visible on the optical lever screen (see attached), and Szymon is confirming whether the L2 drive is now functional.
OK now we have all the HEPI Actuators attached & released at the correct elevation and IAS has signed off on the position. Elevation & level is 0.1mm below nominal of -250.5mm (wrt LIGO Global) with a +-0.1mm levelness. Attached is my field notes of the final dial indicator readings and the level survey-enjoy. Thanks to Mitchell & Jason
I misspeak above where I say wrt LIGO Global. The number above, -250.5mm is the LIGO Global elevation corrected to the local leveling field. The HAM ISI Optical Table is positioned to -252.9mm. 2.4mm is the correction to local level hence the -250.5mm; please pardon the confusion. -H
For more information on the alignment process, see my previous alog (3484)
Summary of tasks performed Tuesday 24th July for H1 and H2:
h2pemey and h2pemeyaux models were changed to move two ACC channels from pemaux to pemey.
Additional HWS slow channels were added to H2EDCU_HWS.ini
New H2 models for h2susitmy, h2susetmy and h2iscey were installed. We verified that ISC EY is communicating over 4km to the SUS ITMY.
H2 DAQ was restarted due to all the above changes.
rsync of h1boot reduced to daily at 05:20 until the epics slow down problem can be resolved.
a new ethercat ethernet cable was ran from the optics lab to the second ecat port on the h1ecatc0 slow controls computer. Software is being installed to convert the ref cav status to an epics channel.
I completed the h1boot /opt/rtcds/userapps/release area. Each subsystem directory here is now a separate SVN working area. It is no longer possible to svn update the entire userapps working area (which has been done accidentally before).
D. Barker, J. Garcia, J. Kissel At the request of the ISC team (see LHO aLOG), we installed the standard QPD readout scheme, ${userapps}/isc/common/models/QPD.mdl part into the L3/Test Mass level of the QUAD's generic library part ${userapps}/sus/common/models/QUAD_MASTER.mdl in order to make the optical lever readout more transparent (because the signals used to be processed inside a bit of c-code). In addition, we hooked up the IPC from the alignment signals to the ITM (where they had only been installed in the ETM up to today), inside ${userapps}/sus/h2/models/h2susitmy.mdl Important notes for others: - I've filled out the OL2EUL (OpticalLever to EULer) matrix in accordance with Thomas' investigations and LLO's precident. However, there's still a good bit of work to do to get the pitch and yaw singals into some sensible units. For, there's a gain of 1e-6 in the OPLEV PIT and YAW filters, so that the values coming out of the bank are not ridiculously huge. - I'm not sure the Saturation or the Divide blocks are functional yet (used in the standard QPD block). With no 1e-6 gain, merely taking (S1+S3)-(S2+S4) shows values of order 1e10 to 1e11. Last I checked [(~4000 + ~4000) - (~4000 + 4000)] / (~4000) was of order 1. - Adding the inter-process communication between ISC and the ITM required adding the appropriate IPC channels to the h2iscey.mdl, which I compiled, but did NOT install or restart. I'll leave that up to the discretion of others. Details ------- Simulink Model Work: In todays work, we modified (and svn committed) ${userapps}/sus/common/models/QUAD_MASTER.mdl ${userapps}/sus/h2/models/h2susitmy.mdl ${userapps}/sus/h2/models/h2susetmy.mdl ${userapps}/isc/h2/models/h2iscey.mdl During the compilation process, the RCG threw us a few curve balls just to keep us on our toes: - As one passes a signal down into sub-blocks -- even though Simulink allows it -- the input and output bubbles can't be named the same thing or else the compiler throws an error claiming the blocks involved are not connected. The assumption is that the parser collects the first instance of the input/output bubble name, makes the appropriate connection, but then skips all other instances with the same name, therefore "not connecting" it. - If you add "receiver" IPC parts, you have to name it a full channel name and that channel name has to match one in the IPC list, /opt/rtcds/lho/h2/chans/ipc/H2.ipc which is generated by the sender models during *their* compilation process. If you put an non-existing channel name in there, the compiler throws and error claiming that there're unexpected characters found before character ";" on lines (x,y,z), because instead of barfing that the channel doesn't exist, it merely fills in nothing, so you end up with a "channel = ;" sort of thing in the resulting code. We've removed the optical lever power monitor from the master model, which prior-to-this-update was taken and used by the c-code. With the c-code gone, that monitor singal is no longer needed. It should be readout by someone eventually though. Perhaps we'll still it in with the monitor models eventually. Because we're stuck with whatever names the filter blocks have in the QPD.mdl libary part, we had to change the stored optical lever framebuilder channels to $(IFO):SUS-$(OPTIC)_L3_OPLEV_PIT_OUT_DQ 2048 $(IFO):SUS-$(OPTIC)_L3_OPLEV_YAW_OUT_DQ 2048 $(IFO):SUS-$(OPTIC)_L3_OPLEV_SUM_OUT_DQ 256 (and note that we also can't have L3_OPLEVINF's any more. These filters are now named L3_OPLEV_SEG[1,2,3,4]). The goal is to have these be the channels which are calibrated into physical units. Added optical lever chain to ${userapps}/sus/common/medm/quad/SUS_CUST_QUAD_OVERVIEW.adl and created a few new screens ${userapps}/sus/common/medm/quad/SUS_CUST_QUAD_L3_OPLEV.adl ${userapps}/sus/common/medm/quad/SUS_CUST_QUAD_L3_OPLEV_SEGS.adl ${userapps}/sus/common/medm/quad/SUS_CUST_QUAD_L3_OPLEV_MTRX.adl which are shown in the attached screenshots.
After all the succes of the RefCav and the PLL, we managed to restore the cavity alignement. We had to do some serious beam steering (with the ITM we steered the beam on either side and top and bottom of the ETM to centre the beam). Once we had some locking going out tdsdither script walked us to the top.
Engaging the PDH (CMB-B) servo initially it seemed to lock ok, but then the servo output started to oscillate between +/-10V. All gains seem ok (we even increased the input from -14 to -10 dB), with a 'UGF' of 11 kHz.
With this oscillation (at the limit), we were seeing the power fluctuations on the REFL_PWR_MON. I left the arm cavity unlocked, but kept the PLL going.
On another note, we did find the moment to align the WFS, so when we get the oscillaitons under control we can get the WFS going ...
[Alberto, Bram]
Today we locked the reference cavity with some optimized settings. We set the knobs in the TTFSS with these values:
COARSE: 690; FINE: 610; COMM: 988; FAST 520; OFFSET 294.
The laser temperature diplay read: 41.064 degrees.
We measured a UGF of 172 kHz.
Two peaks appeared initially in the loop gain measurements at about 2.4 Hz and 4 Hz. We found that the first was due to the cleam room HEPA filters and the second one was the cavity motion due to us touching the table.
I measured the transmitted beam of the RefCav which is monitored by a thorlabs PD (also it hits a Watec CCD, and of course into the fiber). the PD is in Beckhoff world and will soom be available in EPICS. At the moment we have an EVO stream of the TV and oscilloscope!
Attached are three plots, the first two with the same frequency span ~0.05 Hz to 50 Hz and the third plot from ~100 Hz to 112kHz. All recorded with an SR785.
The first plot is the transmitted power readout form the Thorlabs PD, with the HEPA filters ON and OFF. There is a reduction of 2 of the 2.75 Hz peak as well as no harmonics. There is a 4 Hz spike appearing. You can see the beam jiggling on the TV monitor.
The second plot is the TTFSS mixer output (on the interface chassis), indicating that these spikes are not seen in reflection.
The third plot is a large frequecy span, of both the transmission PD and the TTFSS mixer output. There are spikes visible which are not in each others signals.
In summary, if we get the cavity locking again, then the 2.75 Hz peak should be smaller with 'no' harmonics. Although a 4 Hz peak will appear ...
The fourth file is a zip of the data and matlab script for the interested ones.
Could the 'pulse-width-modulation' effect (lack of a better discribtion), and the drift of the beatnote away from the LO, be the reason that the laser is behaving strange?