Dave [WP#4929] new models for h1calex, h1caley. Same functionality, split code into a common library part. May install h1calcs on h1oaf0 if the specific_cpu assignments can be verified for this front end. DAQ restart is required.
Dave: Reconfigure EDCU for latest Beckhoff and resync to guardian. Restart DAQ.
Jeff K, Stuart A: possible SUS model optlev changes, DAQ restart required.
Dave: recompile h1lsc against older version of RCG to fix slow-data-channel-offset-in-daq problem which was reintroduced last week
No other work planned.
They are not 'prepared' yet but that is but a moment. So this uses TF data from 4 Sept 2013 but with the correct Local <--> Cartesian matrices. Additionally, these are Hugo's Generic Controllers in use already on HAMs 4 5 & 6; we'd like to use these where ever we can. Otherwise I attach them here if you wish to look at them. A few of the dofs have phase margins less than 30; but, our problem at EndX had only 20 degrees of margin.
I plan to 'prepare', load , and test them tomorrow morning.
9:00 Bubba to LVEA measuring cleanrooms
~10:58 Rai and Kyle to EY removing ionizer setup
12:00 Rai and Kyle back from EY
1:00 Cris and Karen to MX and MY respectively
1:45 Karen leaving MY
Alastair
The flipper mask holders are installed on the X and Y tables. Both are cables up and working using a 'caput' command. At the moment they won't work using the MEDM screen since this requires checking the state of the flipper (up/down) using sensors that are not yet on the table.
Final outstanding intstall work is : X-table needs 1 flipper sensor. Y-table needs 2 flipper sensors, FLIR camera and baffles around PDs.
The difficulties with H1 DRMI locking, and with getting H1 to full lock, prompt me to survey the top level configuration differences between H1 and L1.
Some other comparisons that should be made (not in the table) are:
At this point we don't know which of these differences, if any, are significant for the lock acquision. Please post comments to this entry if you have some ideas on this, or if there are other known differences that we should be looking at.
parameter | L1 | H1 | comments |
---|---|---|---|
input power for locking | 2 W | 10 W |
|
modulation depths, 9/45 MHz | 0.25/0.29 | 0.19/0.28 |
not sure if L1 values are current |
ETM global feedback | hierarchical | distributed |
|
SUS local damping | A | B |
They're different; see G1401267; Jeff K and Stuart A are working on comparison plots |
DRMI ASC servos | 4 loops | 3 loops |
BW probably lower on H1; more complete comparison needed |
HSTS feedback & coil drivers | increased M2 drive for PRM & SRM | increased M2 & M3 drive for all HSTS | |
LSC servo loops |
comparison needs to be made |
||
3-f PD photocurrent (DRMI) | 0.15 ma | 27 mW -> 3 ma |
H1 has done limited trials with a reduced photocurrent |
WFS centering loops |
different, but comparison needed |
||
ALS ETM feedback | ? | Done when needed to bring frequency in range | |
Michelson contrast defect: modeled, no arms, no TCS | 6400 ppm | 10,800 ppm |
SIS model, using as-built ITMs |
Modeled power recycling gain: carrier, no arms, no TCS | 40 | 33 |
SIS model, using as-built ITMs |
RF spectra from the 3-f BBPD have been posted to both LHO and LLO logs recently, so here is a comparison of those.
LLO data: log 15430 , photocurrent: 0.21 ma
LHO data: log 14807 , 27 mW -> inferred photocurrent: 3.0 ma (better would be a direct measurement of photocurrent)
Comparison of 6 highest RF peaks:
Frequency | L1 | H1 | Delta |
---|---|---|---|
9 MHz | -41 dBm | -11 dBm | +30 |
18 MHz | -29 dBm | -12 dBm | +17 |
36 MHz | -18 dBm | -1 dBm | +17 |
45 MHz | -30 dBm | -12 dBm | +18 |
54MHz | -25 dBm | -6 dBm | +19 |
90 MHz | -33 dBm | -14 dBm | +19 |
Other than 9 MHz, the BBPD output RF components on H1 are all about 20 dB higher than the corresponding components for L1. This is about what is expected from the higher photocurrent used on H1 -- in fact we'd expect closer to 24 dB, if the inferred H1 photocurrent is right. The 9 MHz on H1 is another 10 dB higher (on top of the 20 dB), which is odd considering that the f1 modulation depth on H1 is smaller. This may indicate that on 3-f locking, there is more of an offset on PRCL (or MICH?) in H1 than L1, or maybe more residual motion.
In any case, L1 can hold a stable DRMI lock with the lower 3-f signal level, but H1 has not been able to so far. The LLO log entry also included demod error signal spectra for the DRMI. I'm hoping someone at LHO can post a comparison of that with the H1 situation.
A reminder that at 2am PDT, the clocks went back one hour to 1am PST. This means the hourly autoburt wrote out two "1am" sets of data, the second one overwriting the first. This can be seen if we look at a GPS time channel in one of the snap files. There gap between the midnight entry and the "1am" entry is 7198 seconds, or 1.999 hours.
Also remember local time is now UTC - 8hr
00:10/h1nds0epics.snap:RO H1:DAQ-NDS0_GPS 1 1.098947755000000e+09
01:10/h1nds0epics.snap:RO H1:DAQ-NDS0_GPS 1 1.098954953000000e+09
02:10/h1nds0epics.snap:RO H1:DAQ-NDS0_GPS 1 1.098958553000000e+09
03:10/h1nds0epics.snap:RO H1:DAQ-NDS0_GPS 1 1.098962155000000e+09
Adjusted REFSIGNAL from -2.02V to -2.06V to bring diffracted power down from ~12% to ~10.8%. I am hesitant to make more aggressive adjustments since last time I did, Rick was surprised that such large adjustments were required. Further investigation? Laser Status: SysStat: Warning “VP program online” is red Output power is 29.4 W (Should be around 30 W) FRONTEND WATCH is active HPO WATCH is red PMC: It has been locked 5 days, 21 hours, 58 minutes. Reflected power is 2.0 Watts and PowerSum = 25.4 Watts. (Reflected Power should be <= 10% of PowerSum) FSS: It has been locked for 15 hour, 22 min. Threshold on transmitted photo-detector PD = 2.20 V (should be at least 0.9V) ISS: The diffracted power is around 10.8% (should be 8-10%) Last saturation event was 1 hour, 34 minutes ago
Morning meeting:
Commissioning:
No commissioners asked for this, but I was curious so I installed Rich's sensor correction filter on the HAM6 ISI. It looks like it does good things, but I've only tried Z so far. I don't really know if there are any optics or useful oplevs on HAM6, so I'll bug commissioners about what metrics they would use at that chamber to measure performance, but the ISI's own sensors show improved performance down to 100mhz and very little re-injection below that. First attached plot is before, second is after. Comparing the upper right plot on each shows the improvement. It's interesting that RX and RY also seem to be improved.
model restarts logged for Sat 01/Nov/2014
2014_11_01 15:27 h1fw1
model restarts logged for Sun 02/Nov/2014
One unexpected restart Saturday. No restarts reported Sunday.
Rana had asked me to perform another sweep of the OMC to measure the modulation depth. The results using a single-bounce beam from ITMY are attached; the observed modulation depths are:
Gamma1 (9MHz) = 0.191
Gamma2 (45MHz) = 0.284
This should be compared to the previous measurements from Sep 28th, and also Kiwamu's measurement of the modulation depth and the recycling gain (and subsequent measurements after an RF amp was installed). There is probably an error of order one percent in these measurements, in particular the 9MHz sideband which is close enough to the carrier peak that it relies on the subtraction of the TEM00 lorentzian. The results above include this subtraction, but my lorentzian fit isn't perfect, perhaps due to the very slight nonlinearity of the PZT drive. The plot attached shows the five mode scans that were used to calculate the Gamma's, the peaks identified as the upper and lower sidebands are marked with black crosses. The measured values for Gamma are consistent (to much better than 1%) between the upper and lower sidebands at each frequency, and from one sweep to the next, so the statistical errors are small. The raw data are here.
(FWIW the mode-matching from ITMY is still 0.91, consistent with the previous measurement and with the predictions from beam propagation.)
Other OMC work: I connected the OMC shutter controller box above ISCT6, the input for channel 1 comes from the ASC-AS_C SUM output fro the transimpedance board, the controller output goes to the trigger on the OMC PZT driver. The polarity of the shutter logic seems backwards, 'open' gives 0V and 'closed' is 5V, also I can't get the trigger to fire using the threshold on the PD input. Probably there is some work to do in Beckhoff-land.
The regular ~1nm variations in ETM coating thickness cast a diffraction ring onto beam tube baffles that may produce excess noise through modulation of retro-reflected light (https://dcc.ligo.org/T1300354). We are considering making an estimate of the noise produced by this effect by shaking the beam tube at one of the baffles with large enough amplitude to produce noise at the current LLO sensitivity (here). In making this noise prediction, it is important to know if the shaking moves more than the one baffle. To answer this, I measured the relative motion and phase of every baffle in a 550m stretch of the beam tube centered on the baffle by the shaker.
The relative motions of the neighboring baffles are shown in Figure 1. The relative motions can exceed 0.1 even for baffles a couple of hundred meters away from the shaker. The motion is also not symmetrical about the shaken baffle. I had a hard time believing this at first and returned to many of the baffle locations, remounting an accelerometer and re-starting the shaker, several times. The relative amplitudes were consistent, as were the phases, except for one early set of measurements at one location. Because the asymmetry suggests a location dependence, I think I will have to measure the motion of neighboring baffles when the experiment is done for real at LLO, a significant increase in the difficulty of the experiment.
I spent some time working on the ISC guardians today, in the hope that we could save ourselves alot of mindless clicking in the coming week. The users guide:
Now there is a generator for states where we sweep some channel and search for the transmitted light, which is used by both COMM and DIFF for a coarse then a fine sweep. This is slow but does work, and will be faster than doing it by hand. After COMM finds the resonance, it is now resetting the VCO set frequency, so that when the set frequency offset is 0, the arms are on resonance. However, there is some kind of a bug in the beckhoff that causes an error in the VCO after this. I will look into it tomorrow, since I try not to work on beckhoff on the weekends.
There is another bug, either in the IMC_LOCK guardian, the node manager, or the way that I am trying to use the node manager. When the IMC goes to its fault state (which usually happens because the FSS has dropped lock) it gets stuck there and won't move on. Dan pointed out that one difference between this and other transitions that seem to be working fine, is that the arrow goes from the fault state to INIT. We tried having it return 'INIT' instead of return True with an edge to INIT, this didn't work either (It got to down and just didn't move on from there).
I've added a goto state called bring_down_nicely to the DIFF guardian. The current DIFF down state gives the suspensions a terrible kick, I think this is not necessary.
The issue you're seeing with the managed IMC_LOCK node is the intended behavior of "MANAGED" nodes. When a managed node undergoes a jump transition, it goes into a "stalled" state whereby it waits for a new request from before proceeding along it's path. This gives the manager a chance to react and coordinate the actions of the subordinate with other subrodinates.
There are two solutions:
I've thought about this before, and I think there is a definite need to have a "watching only" manager mode that doesn't put the subordinate into MANAGED mode, but allows the manager to monitor it's progress with the same NodeManager interface. I'll work on adding that to the next guardian release.
Rana, Alexa, Sheila, Peter, Evan
Given last night's strange behavior from REFLAIR_B, we wanted to check the RF powers coming out the BBPD and going into the ISC rack.
With DRMI locked (on 1f, and then on 3f), we used the HP4395A to take an RF spectrum of the "direct" output of the REFLAIR_B diplexer board. This should be the raw RF signal out of REFLAIR_B, with 12 dB of attenuation from a coupler inside the diplexer.
The spectra (adjusted for the 12 dB coupler) are attached.
For 27 MHz, the power into the diplexer is -41 dBm. Using the diplexer schematic (D1300989), this should give -23 dBm at the diplexer's 3x output, which is well below the compression point of the amplifier (ZHL-500HLN+; 1 dB comprsesion occurs at +16 dBm). Similarly, for the 15x output we expect -13 dBm.
The analogous LLO measurement is at LLO#10494.
Power levels were as follows:
Dan remeasured the modulation indices (LHO#14801).
A quick estimate of the amount of distirtion in the BBPD amplifiers (MAR-6SM+ and GALI-6+):
The total amount of RF power in the attached spectrum is about +1 dBm (coming mostly from 4f1). Before the GALI-6+ in the BBPD, that's −11.2 dBm at the output of the MAR-6SM+.
The output-referred IP3 of the MAR-6SM+ is +18.1 dBm. Assuming the third-order distortion of the amplifier grows like the cube of the input power, this means the expected power of the third-order distortion is −11.2 dBm − 2×(18.1 dBm + 11.2 dBm) = −70 dBm out of MAR-6SM+. Then after the GALI-6+, the distorted power is −58 dBm.
[Koji, Rana]
The preamp chain of the BBPD was electrically tested. It turned out that intermodulation can explain the observed RF signals at 27MHz and 135MHz.
Method:
A spare BBPD at the 40m was used for this test.
The photodiode was removed from the BBPD circuitry and an SMA connector was soldered instead. (Attachment 1)
The measurement setup is depicted in Attachment 2.
The RF signals from two signal sources were combined with a power combiner and fed to the modified BBPD.
The output was connected to a network analyzer in order to monitor the output levels at each frequency.
Measurement 1:
Firstly, Intermodulation produced from strong 9MHz and 35MHz components was tested.
WIth these two signals injected, our taget signals appear at 26MHz and 44MHz.
This way we can avoid the interference by the third harmonic distortion of the 9MHz signal.
The result is shown in Attachment 3. The 9MHz and 35MHz input levels were adjusted such that the output levels are -10dBm and 0dBm respectively.
These levels were obtained from the measurement in alog14807 (above).
It is clearly seen that symetric intermodulation appeared at 26MHz and 44MHz. The intermodulation level is linear to the level of the 35MHz signal.
In fact, -10dBm@9MHz and 0dBm@35MHz explain -40dBm@26MHz which Evan observed in the inlock spectra.
Measurement 2:
In the second measurement, it is tested if the intermodulation can produced enough amount of 135MHz signal.
Evan's measurement shows that both 45MHz and 90MHz have -15dBm.
From the lmitation of my setup, I had to use 30MHz and 80MHz to produce 110MHz, instead.
This indeed produced the 60dBm intermodulation, which is consistent with Evan's measurment.
Meaning of this measurement:
What happens if the intermodulation overwhelms the intrinsic signals at 27MHz and 135MHz?
- The intermodulation without fluctuation itself imposes unreasonable offsets in the 3f signals at DC.
- Power fluctuation of the sideband power in the 36MHz (f1-f2) or 91MHz (2xf2) causes unnecessary (=meaningless) signal to the 3f demodulated signals.
- The londitudinal IFO error signals in the 9MHz or 45MHz signals are imprinted to the 3f signals at a certain unknown demod phases,
and thus screw up the demod phase of 3f signals, as well as the immunity of them against the carrier audio sidebands.
Remedy:
- Lower the light power on the PD, if possible to maintain lock.
- Notch out/filter out unncesessary RF components before the BBPD preamps by adding components on the BBPD boards.
- Use resonant type photodetectors in stead of the broadband one to selectively amplify the desired lines.
This is related to Hugh's log 14774. To elaborate a bit on Hugh's log, I made a measurement with Stage 1 Damped only and HPI isolated. The first plot shows the GND_T240_X , ST1_T240_X and HPI L4C (out of loop witness). There was no coherence with ground below 0.1 Hz but there was significant coherence with HPI L4C. This meant that HPI was somehow introducing excess low-frequency motion.
We then did the same measurement on ETMY and saw no such excess motion. The second pdf shows the corresponding measurement. Stage 1_Y was very coherent with ground_Y. Jim mentioned he had modified the HPI controllers on ETMY as described in Hugh's log, so we decided to try the same on ETMX in X and Y.
This has made a significant difference to the low frequency performance of Stage 1 as shown in the third file. Performance below 0.1 Hz is much closer to ground motion now.
Some more plots of the old vs new isolation filters, per Jeff's request. I dug into the foton file to find numbers to back up what I thought the original design was. The gains of the old and new foton filters are shown in the first image, they show that not much was done to the filter design, just that the gain was reduced. Solid lines are the old design(higher gain, UGF), dashed lines are the current design. Second and third images are the currently installed plant design and a reconstruction of the orignal design (no plots were found from the original design from earlier this year). The solid and dashed orange lines tell most of the story, mostly we just cut the UGF to 2hz, and modified the boost to get more phase margin. No idea why this affect the very low frequency noise, Jeff and Krishna suggested maybe we were re-injecting IPS noise with the higher gain.
Here is another look at the controller with the amplitude scale zoomed out to see the lowest frequencies of the open loop.
J. Warner, K. Venkateswara
We repeated this measurement today and did not see the same results. Sensor correction was off. The attached pdf shows the before (old controller) and after (new low gain UGF controller) data. Very strange. We may have been fooled by different ground motion or perhaps by sensor correction. There is good coherence with ground till ~60 mHz in either controllerconfiguration.
Jim has reverted to the new low gain UGF controller as it should help with ringing of HEPI at 9 Hz.
The current cdsutils installation (r361) has a new and improved NDS avg() function. The previous version was buggy, was calculating the standard deviation incorrectly, and had a clunky interface. This new version fixes those issues:
The standard deviation was previously being calculated incorrectly and the returned values were wrong (off by some unknown but kind of large factor). The new version uses the python numpy.var() function to calculate the variance, from which the standard deviation is calculated. It has been verified to be correct.
Previously, the avg() function required full channel names, with IFO prefixes. This new version works like the ezca interface whereby the IFO prefix can be left off of the channel name. This makes things much cleaner, and allows scripts to be portable. E.g., instead of:
cdsutils.avg(2, IFO+':LSC-DARM_OUT')
just do:
cdsutils.avg(2, 'LSC-DARM_OUT')
Probably the thing that's going to cause the most trouble is that the interface to the function has been fixed up. Previously, the function was returning a dictionary of channel:avg key pairs. This was very clunky to use.
The return value of the function now mirrors the input argument. So for instance, if a single channel is requested, a single avg value is returned. If a list of channels is requested, a list of average values is returned, in the same order as the input channel list. So calls like:
avg = cdsutils.avg(2, 'LSC-DARM_OUT').values()[0]
can now just be:
avg = cdsutils.avg(2, 'LSC-DARM_OUT')
If the stddev option is provided, the output will be an (avg, stddev) tuple, or if multiple channels is requested, a list of such tuples, e.g.:
avg, stddev = cdsutils.avg(2, 'LSC-DARM_OUT', True)
I have fixed all calls to cdsutil.avg() that I could find in the USERAPPS/release. I likely didn't catch everything, though, so be aware of the new interface and update your code appropriately.
controls@opsws5:sbin 0$ cdsutils -h
I pushed a new version of cdsutils (r366) that fixes the issue with the help. Commands were being intercepted by one of the gstreamer libraries:
jameson.rollins@operator1:~ 0$ cdsutils -h
usage: cdsutils
Advanced LIGO Control Room Utilites
Available commands:
read read EPICS channel value
write write EPICS channel value
switch read/switch buttons in filter module
sfm decode/encode filter module switch values
step step EPICS channels over specified range
servo servo EPICS channel with simple integrator (pole at zero)
trigservo servo EPICS channel with trigger
avg average one or more NDS channels
audio play NDS channel as audio stream
dv plot time series of NDS channels
water NOT SUPPORTED: No module named PyQt4
version print version info and exit
help this help
Add '-h' after individual commands for command help.
jameson.rollins@operator1:~ 0$
The "junk" messages, as you refer to them, in the avg output are actually just logging that are going to stderr, and therefore do not affect the stdout output:
jameson.rollins@operator1:~ 0$ foo=$(cdsutils avg -n 2 H1:LSC-MICH_IN1)
ignoring first online block...
received: 1098998811 + 1.0
received: 1098998812 + 1.0
jameson.rollins@operator1:~ 0$ echo $foo
75.2394218445
jameson.rollins@operator1:~ 0$