I'm not sure what's going on today but we're seeing ~80% packet loss on the 40MARS wireless network. This is obviously causing big problems for all of our wirelessly connected machines. The wired network seems to be fine.
I've tried power cycling the wireless router but it didn't seem to help. Not sure what's going on, or how it got this way. Investigating...
I'm still seeing some problems with this - some laptops are losing and not recovering any connection. What's to be done next? New router?
Could be that this is OK, but it doesn't yet make sense to me. Can you please explain in words how this manages to apply the calibration rather than just add an extra gain to the phase tracking loop?
I have modified the ALS model to now include PHASE_OUT calibration for both X and Y. MEDM screen has not been edited to include these yet.
Following the circuit design in elog 8748, I constructed a prototype for the servo portion of the ISS (not including the differential amp) to be used in the CTN experiment. The device was built on a breadboard and its transfer function was measured with the Swept Sine measurement group of an SR785. For various excitation amplitudes, the transfer function (TF) was not consistent.
Recall the ideal transfer function for this particular servo and consider the following comparisons.
This gain limitation is problematic for characterizing prototypes as my particular servo has very large gain at low frequencies.
At the risk of looking too deeply into the above data,
Unfortunately, the noise was too large for lower excitation amplitudes to be used to any effect. I'll try this again tomorrow, just as a sanity check, but otherwise I will proceed with learning Altium and drawing up schematics for this servo.
Steve and I tried to fix the Oplev situation detailed in elog 8684, today afternoon. We have come up with a fix which needs to be adjusted, possibly completely overhauled depending on whether the mirror steering the return beam to the QPD is blocking the POX beam coming out.
Situation in the chamber: the black line is meant to indicate what was happening, the red is indicative of the present path.
Plan of action:
I've restarted the NDS2 process on Megatron so that we can use it for getting past data and eventually from outside the 40m.
1) from /home/controls/nds2 (which is not a good place for programs to run) I ran nds2-megatron/start-nds2
2) this is just a script that runs the binary from /usr/bin/ and then leaves a log file in ~/nds2/log/
3) I tested with DTT that I could access megatron:31200 and get data that way.
There is a script in usr/bin called nds2_nightly which seems to be the thing we should run by cron to get the channel list to get updated, but I' m not sure. Let's see if we can get an ELOG entry about how this works.
Then we want Jamie to allow some kind of tunneling so that the 40m data can be accessed from outside, etc.
I have done the following:
* installed the nds2-client in /ligo/apps/nds2-client
* moved the nds2 configuration directories to /ligo/apps/nds2/nds2-megatron
* set up a cron job to update the channel list every morning at 5 am. The cron line is:
15 5 * * * /usr/bin/nds2_nightly /ligo/apps/nds2/channel-tracker /ligo/apps/nds2/nds2-megatron
cron will send an email each time the channel list changes, at which point you will have to restart the server with:
* restarted nds2 with updated channel lists.
Not sure why it was so poorly aligned, since the misalignment "event" happened while we were all away at lunch, but I steered the MC optics until their SUSYAW and SUSPIT values were about the same as they were before they got misaligned. MC autolocker took over, and things are back to normal.
Having established the serial link between the Doubling oven at the Y-end and the Raspberry pi, I wanted to use this interface to collect time-series from the oven after applying a step function in an effort to measure the transfer function of the oven. The idea was that knowing the transfer function of the oven, I could use some simple PID tuning rules like the Ziegler-Nichols rule or put everything in SIMULINK and find the optimal PID gains. However, I am unable to extract the oven transfer function from the time series data collected.
Last night, between 920pm and 940pm I applied a step function to the doubling oven by changing the setpoint of the controller from 35.7 Celsius to 39 Celsius (having checked elog 3203 to get an idea of a 'safe' step to apply). I then used the Pi to collect time series data for 6 minutes, then returned the set-point back to 35.7 Celsius, and took another time-series to make sure things were back to normal. Having gotten the time series data, I attempted to fit it using some exponentials which I derived as follows:
I couldn't think of a way to get the laplace transform of the time-series data collected, so I approximated the oven transfer function as a system with a one simple pole i.e. G(s)=K/(1+Ts), where K and T are parameters that characterise the oven transfer function. I then plugged in the above expression for Y(s) into Mathematica (knowing X(s)=constant/s, and H(s) = 250 + 60/s +25s from the PID gains) and did an inverse laplace transform to find a y(t) with two unknown parameters K and T to which I could fit the time-series data.
The time-series data collected via the Pi after applying the step was this:
The inverse laplace transform from mathematica yielded the following (formidable!) function (time, the independent variable, is x, and the fitting parameters are a=K and b=T where K and T are as described earlier):
(39*(exp(x*(1/(2*(25*a - b)) - (125*a)/(25*a - b) - sqrt(1 - 500*a+ 56500*a^2 + 240*a*b)/(2*(25*a - b)))) - exp(x*(1/(2*(25*a - b)) - (125*a)/(25*a - b) + sqrt(1 - 500*a + 56500*a^2 + 240*a*b)/(2*(25*a - b)))))*a)/sqrt(1 - 500*a + 56500*a^2 + 240*a*b)
My best attempts to fit this using MATLAB's cftool have given me useless fits:
I tried changing the start-points for the fitting parameters but I didn't get any better fits.
I have added more DAQ channels to the c1als model. Installed and restarted the model on c1ioo. Frame builder restarted.
DAQ channels added:
With Rana's help/supervision/suggestions, I have closed the loop on the PRMI ASC servo with the new QPD. I think I've had it locked for ~30+ minutes now. It was locked for ~45 minutes, but then the MC momentarily lost lock. I immediately recovered the PRMI+ASC (after small PRM yaw tweaking, since the ASC isn't triggered yet, so the MC lockloss caused a big yaw step function to go to the PRM, which displayed a bit of hysteresis.).
My biggest problem was that I didn't really understand Koji's servo filter choices, so I wasn't using the right ones / doing good things. In particular, I need to compensate for the oplev servo filters. The oplev servo shape is something like ^, so the 1/(1+G) shape is something like =v= (ignoring the lower horizontal lines there). For tonight, we just turned off the PRM oplevs, but clearly this isn't a permanent solution. (Although, after Rana went in and roughly centered the PRM oplev, we noticed that turning the oplev on and off doesn't make a huge difference for the PRM....we should investigate why not. Also, we turned off the FM2 3.2Hz resonant gains in the PRM oplevs, since the Q of those filters is too high, much higher than our actual stacks).
Rana and I also locked the PRM-ITMY half cavity, and used that beam to realign the beam onto the POP QPD, POP110 PD, and the camera.
The POP QPD pitch and yaw signals with the half cavity have some noise, that looks like 60Hz crap. Since this goes away (rather, is much less noticeable) with the regular sideband-locked PRMI, we suspect this is a problem with perhaps the normalization, with the sum very low, and having some noise on it.
Once we had our ASC filters set up (not the 10Hz boost yet though, I think), if I increased the gain from -0.02 to -0.03, we start to get some gain peaking. With a gain of -0.04, the peak is very noticeable around 250Hz. We aren't sure where this is coming from, since it shouldn't be coming from the ASC loop. The UGF of that loop is much lower (I measured it, to check, and the UGF is ~5Hz). Anyhow, this is still a mystery, although the gain of -0.02 holds the cavity pretty well.
I measured the power spectra of the POP QPD pit, yaw, sum, as well as POPDC and POP110I, with the ASC loop on and off (dashed lines are with the loop on. You can see that the yaw motion as seen on the QPD was reduced by almost 2 orders of magnitude below 1Hz. It also looks like we can win some more by turning on the equivalent pitch ASC servo (this is also something we see when looking at the dataviewer traces).
I also tried to measure the PRMI sensing matrix, but I get some weird results, even after I double the drive actuation. I need to be checking whether or not my drive is actually coherent with the error signals that I'm seeing, because right now I'm not sure that I believe things. I'm going to leave that on the to-do list for tomorrow night though.
* Engage POP QPD -> pitch loop, copying yaw loop.
* enable ASC triggering
* model PRMI sensing matrix and error signals, bringing one arm into resonance
* Lock the PRMI, and bring the Xarm into IR resonance using the ALS system.
Here are some numbers and plots from the night:
Right now, I'm locking the LSC with:
MICH LSC with AS55Q, FMs 4 and 5 on, FM 3 is triggered, gain = -40.0, normalized by sqrt(POP110I)*0.1
PRCL LSC with REFL33I, FMs 4 and 5 on, FM 9 is triggered, gain = +2.5, normalized by sqrt(POP110I)*10
(FM3 of MICH and FM9 of PRCL are the same, just in different spots).
The ASC (only POP yaw -> PRM yaw right now) has:
FMs 1,2,5,6 on (1 = integrator [0:0.1], 2 = 3.2 res gain, 5 = [1000,1000:1 and gain of 0.01], 6 = 10Hz boost). Gain = -0.020, Limit=5000.
Turn off the input, turn on the output and the gain, clear the histories (to clear out the integrator in FM1), then turn on the input.
PRM oplev is OFF. (need to put in a filter to compensate for it in the ASC servo, but for tonight, we just turned it off.)
We measured the spectra of the POP QPD signals with the ASC loop on and off:
I also measured the ASC loop (with the PRM oplev still off):
(sorry about the separate plots - I can't make DTT give me more than 2 plots on a page at a time right now, so I'm giving up, and just making 3 separate pages)
Weird sensing matrix, unsure if I'm really getting good coherence:
For quite a while (no one knows how long), we've seen fluctuations in the 10-30 Hz seismic motion. This shows up as the purple trace on the seismic BLRMS on the wall projector.
The second plot shows that this is not only a periodic increase in the usual 29.5 Hz HVAC peak, but also an anomolous 32.2 Hz peak. Probably some malfunctioning machinery - maybe in the 40m or maybe on the roof.
Beat note setup
I had some problem with the Oplev Servo today. I was working at the mode matching fine tuning and I left the Oplev servo enabled while aligning.
When I opened the Yend table lids, the Oplev beam started moving on the QPD and the Oplev servo didn't help in stopping the mirror movement, but it increased it.
So, the mirror was oscillating at a frequency of a few Hz
Koji suggested that maybe the shaking is due to the air conditioning moving the beam, so the servo tries to feed back the signal to the mirror, even if the mirror doesn't actually move.
I also measured the transfer function for the Oplev, but it didn't show any strange behavior.
Following Tara's noise budget, I have developed the following ISS, whose transfer function was computed with LISO and is also displayed below. The transfer function was computed from the output of the differential amplifier circuit (i.e. it does not include the portion of the schematic in the dashed box). The differential amplifier is included for completeness. Essentially, the resistor values of this portion (and even the voltage reference if need be) can be modified to handle various signals from PDs in different experiments. Some filtering may also be applied to the signal from the voltage reference. In previous designs for the ISS, a ~30 mHz low-pass filter applied to the output of the voltage reference has also been proposed.
LISO was also used to compute the input-referred noise of this circuit. Using the response function of Tara's PD the noise spectrum was converted from [V / sqrt(Hz)] to [W / sqrt(Hz)] and then subsequently converted to a frequency noise spectrum, specifically [W / sqrt(Hz)] to [Hz / sqrt(Hz)], using the following transfer function which couples RIN to frequency noise in the CTN experiment. In these particular units, we can make a direct comparison between the inherent noise contribution from the servo itself and other more significant noise contributions shown earlier in Tara's noise budget. Indeed, the servo contributes significantly less noise.
This servo has been prototyped on a breadboard and will soon be characterized with the SR785. Additionally, schematics will be drawn up in Altium and eventually put on PCB.
Additional servos for other experiments can be designed once various requirements for noise suppression are explicitly formalized.
From the ALS overview screen, opening up the ETMX and ETMY screens gives these white fields. The PV info indicates that the blank fields were made with some macro variable substitution that didn't work well.
Why are these different from the SUS screens I get from the sitemap?
This entry is meant to be a sort of inventory check and a tentative plan-of-action for the installation of the PZT mounted mirrors and associated electronics on the Y-endtable.
High-Voltage Power Supply
Situation at rack 1Y4
I have been working on setting up a serial-link with the temperature controller of the PPKPT crystal doubling oven at the Y-end for some time now. The idea was to remotely tune the PID gains of the controller and get temperature data. The device used to serially interface with the temperature controller is a Raspberry Pi model B, which is connected to the temperature controller by means of a USB to serial adaptor with a PL2303 chip. I installed the interface this morning, and have managed get talking with the doubling oven. I am now able to collect time-series data by ssh-ing to the Raspberry Pi from the control room. I will use this data to manually tune the PID gains for now, though automatic tuning via some script is the long-term goal.
The temperature controller for the doubling oven is a Thorlabs TC200, and supports serial communication via the RS232 protocol by means of a female DB9 connector located on its rear panel. I have hooked up the Raspberry Pi to this port by means of a USB-Serial adaptor that was in one of the cabinets in the 40m control room. After checking the Martian Host Table, I assigned the Raspberry Pi the static IP 192.168.113.166 so that I could ssh into it from the control room and test the serial-link. This morning, I first hooked up the Raspberry pi to an ethernet cable running from rack 1Y4 to make sure I could ssh into it from the control room. Having established this, I moved the raspberry pi and its power supply to under the Y-endtable, where it currently resides on top of the temperature controller. I then took down the current settings on the temperature controller so that I have something to revert to if things go wrong: these are
Set-Point: 35.7 Celcius
Actual Temperature: 35.8
I then connected the Pi to the temperature controller using the serial-USB cable, and plugged the ethernet cable in. Rebooted the Pi and ssh-ed into it from the control room. I first checked the functionality of the serial-link by using terminal's "screen" feature, but the output to my queries was getting clipped on the command line for some reason (i.e. the entire output string wasn't printed on the terminal window, only the last few characters were). Turns out this is some issue with screen, as when I tried writing the replies to my queries to a text file, things worked fine.
At present, I have a python script which can read and set parameters (set-point temperature, actual temperature, PID gains)on the controller as well as log time-series data (temperature from the temperature sensor as a function of time )to a text file on the Pi. As of now, I have only checked the read functions and the time-series logger, and both are working (some minor changes required in the time-series function, I need to get rid of the characters the unit spits out, and only save the numbers in my text-file).
For the time-being, I plan to apply a step to the controller and use the time-series data to manually tune the PID parameters using MATLAB. I am working on a bunch of shell scripts to automate the entire procedure.
My understanding is that that number is an in-loop evaluation of the loop so far (as the first step of the loop evaluation).
This is not what we can directly compare with the number in the paper.
Basically the entry 8741 is telling us that the new filter suppresses the error signal better than before.
That's clearly shown in the attachment 2.
RMS is now less than 1 kHz or ~50 pm. (in your face, Kiwamu!)
Isn't this still a factor of 2 away from the limit in the paper?
Alex Cole and Craig Cahillane received 40m specific, basic safety training last week.
ALS noise suppressed to 1KHz/rtHz. 1kHz RMS.
Plot 1: Scan of X arm by changing offset into Phase Tracker -> Xarm loop. Filter bank ramp time set to 120 s + using a 30 mHz low pass filter. IR beam is aligned to x arm, but not well.
Plot 2: ALS error signal with loop open (BLUE), closed with old filters (PURPLE), and with new, better boost (RED).
Plot 3: Bode plot of new boost (FM10), v. old, sad boost (1:50 pole:zero). RMS is now less than 1 kHz or ~50 pm. (in your face, Kiwamu!)
Changes made to the ALS servo:
ALS-TRX has been calibrated to read from 0-1 instead of counts in 1000 s. Calibration factor = 1/4500 = 0.00022
Old antiwhitening filter has been removed. Added LPF at 1000Hz to remove glitches at high frequencies.
No changes made.
FIlter FM5 modified. 1000:1 changed to 3000:1
5. Offset for ALS scan were given through C1ALS_OFFSETTER1 with LPF50m enabled.
The filter modules of the servo were:
Check PZT out range for ALS. Figure out what the deal is with ALS SLOW servos.
Add DQ channels for ALS.
Automatic ALS up script (enable and disable phase tracker included).
I have finished my work on the LSC and ASS models for now. The triggering is all implemented, and should be ready to go. There are no screens yet.
I have *not* compiled either the LSC or the ASS, since Rana and Manasa still have the IFO.
I am working on making the Proto-ASC less "proto". I have put IPC senders in the LSC model to send the cavity trigger signals over to the ASS model, for ASC use. I'm partially done working on the ASC end of things to implement triggering.
LSC should be compile-able right now, ASS is definitely not. But, I expect that no one should need to compile either before I get back in a few hours. If you do - call me and we'll figure out a plan.
I am working on the basic ALS servo model. The simulink model for the same is attached. The loop is not yet complete (I'm still debugging it) ; but this is just an update of where I am right now.
Attached is the simulink and matlab file.
This is nice - how about figuring out how to plot the measurement and model on the same plot? I guess we need to figure out how to go from counts to Watts.
I haven't done a units conversion for the measured vs. modelled plot, but at least we can compare the separation between the different degree of freedom signals. Figuring out why the REFL11 measurement and models are so different is still high on my to-do list. But at least the measurements that were taken last month are consistent with one another. EDIT: The separation angles match up pretty well between the 2 sets of measurements, but the overall rotation isn't really consistent. I do not believe that the phase rotation values that we're using online changed between the measurements, so the I&Q lines should be the same for both seets of measurements....however, I did not write down the phase rotation values at the time of the first measurement, so there's a chance that they were different. Also, something that I need to monitor is the coherence of my measurement, to make sure I'm really driving and measuring something.
2 measurements, with overall rotation arbitrarily rotated to make MICH lines match up:
Same 2 measurements, without the arbitrary overall rotation:
Measurement vs. Model, with the *modelled* phase arbitrarily rotated:
The 3 Panasonic Ceramic Kits Books, 1206 NPO, SMT are well stocked. The 4 th one needs to be refilled at some values.
I labeled them on the cover for fast access. See Atm1
The Metalized Polyester Film Book with through holes mount are in good shape also. Atm2
The AVX Ceramic 1206, Garrett cab, range: 1pF - 22 microF 50V...... 67 values
Note here: that the value of dielectric, capacitance / voltage will vary
NPO: 1 pF - 1 nF / 50V .......37 values
X7R : 1 nF - 0.082 microF / 50V, 0.1 microF / 100V.......27 values
Y5V: 4.7 microF / 6.3 V, 10 microF / 10V, 22 microF / 6.3V.........3 values
I wanted to make sure that the QPD map on the C1IOO_MC_TRANS_QPD.adl screen corresponded to the actual physical quadrants on the photodiode at the MC2 table. We turned MC_WFS_OUT OFF before fiddling around with a red laser pointer to try and map the quadrants.
I initially verified the correspondence between the various quadrants and the text-fields displaying the outputs using PV_Info. I found that there was good agreement in this respect. So for instance, field adjacent to the quadrant marked "1" on the C1IOO_MC_TRANS_QPD.adl screen had the following input channel: IOO_MC_TRANS_SEG1_INMON. The filter banks were empty and there was just an overall gain on -1 on all four channels. The channels leading to the filter-banks were the 'right' ones: quadrant 1 for the top bank, then quadrants 2,3 and 4 down.
Next, a red laser pointer was used to map the quadrants. Here, there was some disagreement between the physical quadrants and the map on the C1IOO_MC_TRANS_QPD.adl screen, which is summarised in the attached image-the whole thing is sort of rotated 180degrees about the centre.
The interpretation of the figure is as follows:
quadrant 1 on screen QPD=bottom right quadrant on QPD
quadrant 2 on screen QPD=top right quadrant on QPD
quadrant 3 on screen QPD=top leftt quadrant on QPD
quadrant 4 on screen QPD=bottom left quadrant on QPD
MC_WFS_OUT was turned back ON.
The ETMY Oplev servo didn't work properly, when it was activated the ETMY moved too much.
We measured the oplev TF for Pitch and Yaw and it turned out that the gain was too low by a factor 3, so we increased the gain from -.250 to -.750 on both.
We also locked the Y arm and we could see that the mirror's oscillations are actually suppressed.
Tried a bunch of stuff, but eventually just turned off the TRANS_QPD loops and loops are stable. Needs more debugging.
Office work benches were cleaned up yesterday. Anti-image filter boards were moved to north wall of the control room. Koji's pd- electronics box placed next to water dispenser.
The removed ETMY optical table: TMC 4' x 2' x 4" with Aluminum enclosure was placed on table in the east arm.
I didn't have any success with the ASC tonight. I copied over the filters that Koji had used in elog 8562, and put them in the new ASC filter banks (and turned them off in the SUS-PRM_ASCYAW bank). I also moved all the old scripts that were in .../scripts/ASC to an OLD subdirectory (the most recent edit is from 2009 sometime). I then copied over the up and down scripts that Koji had written for his ASC test into the ..../scripts/ASC directory, and modified them to work with my new channels.
I then tried locking, and wasn't very successful. Actually, my best lock, ~4 minutes, including tweaking up the PRM alignment, was when the ASC path was off (even though I thought it was on). After discovering my mistake, I tried locking for another hour or so, but haven't really gotten anywhere. The lock stretches I'm getting are rarely long enough for me to get to the terminal and run my up script, and the maybe ~6 or 7 times I've been able to run it, I haven't converged toward finding a good gain value for the PRC yaw loop. At some point, I redid the MICH alignment since it had drifted away a bit, but that didn't really help.
I think that one of the next things I might try is carrier-locking the PRMI, to find okay loop gain settings for the ASC path. Since the QPD output is already normalized (I'd have to custom-make some electronics to make it non-normalized), I think the gain should be the same for both carrier and sideband lock cases.
Once I finally get a good, stable, PRMI sideband lock, I think I need to take the following measurements:
* CTRL and ERR spectra for MICH and PRCL
* TFs for MICH and PRCL loops
* Sensing matrix, including AS55, REFL11, REFL33, REFL55, POX and POY.
---->> Are there any others?
This is a mid-evening update, so I don't forget all the stuff I've already done.
Aligned PRMI, no nice flashes on POP110. Aligned and locked PRM-ITMY half-cavity on the carrier, and used that POP beam to center the beam on the POP110 PD. I also turned on the new QPD and centered the beam on it.
Notes about QPD setup: The "zero/cal" switch is OFF, so none of the small knobs on the front (basically, everything but the gain knob) should be bypassed. The gain knob is set to position 3. This is the highest gain that I can have without the "too much light" saturation light blinking on the front panel. (During this time, POP110I is flashing around 200 counts).
I made a super hacky ASC screen, which is accessible from the ASC button on the sitemap. While there is a pitch path in the model, I only put in the yaw elements (except for the QPD readouts) in the screen, since that's what I'll be using for now.
I added filter banks to the front side of the ASC subblock in the ASS model, so that I have a place to monitor the QPD signals on the screen and with striptool.
Using the settings that Koji recorded in elog 8521 in the "Locking with SQRT(POP110I)" section (and no ASC engaged so far), I can lock the PRMI for ~10 or 20 seconds, at 150 or 200 counts on POP110I. So, I'm doing well so far, and next up is to copy the ASC filters Koji made in elog 8562, and try the new ASC.
Something has happened that all of the C1:LSC-dof_NORM_SQRT_ENABLEs are disabled, but normally some are enabled and others are not.
In the hopes that miraculously this change happened after Jamie restarted the conlog this afternoon, I checked the conlog. These channels, however, were not recorded.
Using the instructions on the conlog wiki page, I added the _MON channels to the conlog list. The one snag I hit was that the medm screen referred to in the wiki isn't usable if you open it by hand using the medm gui, since it needs to know what IFO you're at to fill in the macro expansion variables. To remedy this, I changed the "FE STATUS" button on the sitemap to "CDS", and added the conlog screen to the list of options.
Now I see that the conlog at least knows about these channels, for future reference.
I put the POPDC cable back to the DC output of the bias tee that is the first thing at the LSC rack that the POP110 PD sees. So, now we should be back to the old nominal PRCL locking, with the addition of the new QPD.
I'm going to give it a whirl.....
I have implemented a proto-ASC in the ASS model.
In an ASC block within the ASS model, I take in the POP QPD yaw, pit, and sum signals. I ground the sum, since I don't have normalization yet (also, the QPD that we're using normalizes in the readout box already). The pit and yaw signals each go through a filter bank, and then leave the sub-block so I can send the signals over to the SUS model, to push on PRM ASCPIT and ASCYAW.
In doing this, I have removed the temporary PRM ASCYAW connection that Koji had made from the secret 11'th row of the LSC output matrix (see Koji's elog 8562 for details from when he implemented this stuff).
LSC, SUS and ASS were recompiled, and restarted. I also restarted the daqd on the fb.
I cleaned up a bunch of conlog stuff to make it all a little more sane and simple. I also fixed the messy startup shenanigans, so that it should now start up sanely and on it's own (using Ubuntu's native upstart system). The conlog wiki page was updated with all the new info.
By the way, I also did confirm that it is running and registering EPICS changes.
Trying to figure out what's wrong with the MC WFS:
1) The symptom seems to be that the control signals become very large in the pitch and then the loop breaks when they saturate. Usually this is due to a degenerate matrix or improper inversion. Most likely some of the BURT restore is bad or the analog gain for one of the WFS has been switched when Jamie was doing the "Guardian" debugging.
2) In checking this out, I found that several buttons on the WFS screens were not working (and apparently have never been working). Please try to test things in the future...The filter bank buttons in C1IOO_MC_TRANS_QPD were using relative path names; fixed these to use abs path names. The buttons in the WFS_MASTER for the IOO_PIT banks were using IOO_PITCH instead...
2.5) Recentered beams on WFS heads with MC alignment good and MC unlocked.
3) Main problem in the WFS still not found - disabling this in the autolocker.
Or we just stuff any angle control things in to Angular Stabilization System without changing the model name.
The process name itself is not a big deal.
Following Jamie's table in elog 8654, I have connected up the channels 0, 1 and 2 from ADC0 on the IOO computer to rfm send blocks, which send the signals over to the rfm model, and then I use dolphin send blocks to get over to the ass model on the lsc machine.
I'm using the 1st 3 channels on the Pentek Generic interface board, which is why I'm using channels 0,1,2.
I compiled all 3 models (ioo, rfm, ass), and restarted them. I also restarted the daqd on the fb, since I put in a temporary set of filter banks in the ass model, to use as sinks for the signal (since I haven't done anything else to the ASS model yet).
All 3 models were checked in to the svn.
1. Calibrating offset :
I measured the shift in the beat frequency while scanning through the offset. Offset stepped by 50 resulted in 1MHz shift of the beat frequency.
2. Anti-whitening filter for beatbox output:
I made an anti-whitening filter for the beatbox output in the ALS_BEATX_FINE_I module by inverting the whitening filters that Jamie had installed in the beatbox earlier (elog). I have kept the old anti-whitening filter in the module as well for the time-being because the new anti-whitening filter was not as good as the old one in stabilizing the servo (large error signals and unstable ALS).
3. Beat frequency scan for 3FSR:
With ALS loop enabled, I did an offset sweep corresponding to 3FSR (FSR = c/2L = 3.7MHz). The loop doesn't seem to be stable enough to reduce the arm fluctuation to get a resonance for IR. Time series of scan is shown below:
4. No-loop and in-loop spectrum:
I measured the spectrum of the error signal (C1:ALS-BEATX_FINE_I_IN1) with ALS loop enabled and disabled. To suppress the peaks at 3.2Hz and 16.5Hz, I turned ON the corresponding filters. I have recorded the error signal spectrum with only 16.5Hz res gain filter turned ON. Turning ON res gain 3.2Hz filter kicked ETM.
Spectrum of error signal shown below:
1. What is wrong with the new anti-whiteing filter?
2. Why would the res gain filters kick ETM and show no noise suppression?
I am proposing a model name change. Currently, we have an "ASS" model, but we do not have an "ASC" model.
The ASS is currently using ~17 of 60 available microseconds per cycle. So, we have some cpu overhead available to put more stuff on that cpu. Like, say, ASC stuff.
So, my proposal is that we change the ASS model name to "ASC", and put all of the ASS-y things in a top_names block, so we retain the current channel names. The IOO top_names block that is in the current ASS model (which is there to send signals to the LSC DAC for the input tip tilts, even though the names need to be IOO) should obviously stay on the top level, so that things in there retain their names.
Then, I can make a new top_names sub-block for ASC-like things, such as the new POP QPD.
Inside the ASC block (in the ASC model), I'm currently thinking something simple will do..... QPD inputs, going to a matrix, which outputs to the filter banks in the "length" degree of freedom basis (PRCL, SRCL, etc), then another matrix, going to the ASC suspension paths.
So, for example, the POP QPD pitch would go to the PRCL_PIT filter bank, and then on to the PRM_ASCPIT path in the SUS screen.
Or, in another example case, IPPOS yaw would go to an input pointing filter bank, then on to TT1's yaw slider.
EDIT: After a few minutes of thinking, I think I also want triggering, and perhaps filter bank triggering, in the ASC model. One of the reasons Koji has been pushing for the new automation system is that when the PRC fell out of lock, the ASC path would kick the PRM until Koji ran a down script. Triggering will fix this issue, and it's the kind of thing that needs to happen quickly, so may not really be appropriate for the Guardian anyway.
I have done a quick update of the IFO_ALIGN screen's save and restore scripts, so that we can now also save, restore, and view the saved values for the input tip tilts.
In the past, there was an "if" statement to check if the optic was a PZT, and if so, define the alignment channels accordingly (since all the SOS suspensions have the same format for the name, and the PZTs were the odd ones out). I have removed the mention of PZTs, and replaced the if statement with an "if TTs" statement, and put in the correct channel names (C1:IOO-TT#_PIT_OFFSET, and the same for YAW).
Also, I caught a bug in the code, which explains some confusing behavior that I had seen in the past. When deciding if the restore script should take small steps or just do a big step, it looked at the difference between the saved value and the current value of the slider. It was *not* looking at the absolute value of the difference. So, if you had misaligned a slider by hand, and it was in the opposite direction of what the misalign script does, the restore script wouldn't realize that the optic needed to be restored in small steps. I have now fixed this bug for both pit and yaw cases of the restore script.
[Jenne, Jamie, Manasa]
Jamie was working on the MC guardian today (I think he will elog about this soon).
After this, I received the MC locked in TEM00 with MC_REFL at ~2.5 counts from Jamie. Usually the WFS would do their job in this case to bring MC to a good locking condition and since this did not happen, I figured out that something was wrong with the MC_WFS.
What we did:
1. The WFS were turned off.
2. As a first step, we wanted to run the WFS_OFFSET script (Koji's elog) which requires MC to be locked with MC_REFL<0.5 and spot positions centered. The autolocker was disabled and MC locked manually to MC_REFL<0.5.
3. While running the WFS_OFFSETS script, Jamie pointed out that the inputs to the WFS servo had been turned off. After the WFS_OFFSET script finished running we turned ON the WFS inputs.
4. Following this, the MC was relocked manually and MC spot positions were measured (all spot positions were decentered by < 2 mm).
5. We ran the WFS_OFFSET script again and turned the WFS back ON. But this would still kick the MC out of lock.
Status: MC is locked with WFS turned OFF. Jamie will be looking through what changes he had made earlier today to fix this problem.
Red-green laser pointers added to the depleted stock of 2011
The two pointers output measured 4.4 mW green and 2 mW red
What's the reason why the PRMI/MICH ratio gets worse (larger) for 55MHz and 165MHz for the DRMI compared to the PRMI case?
It locked at almost 280 cts, and the transmitted power on the PSL table is about 40 uW.
To make it lock on the carrier I had to flip the sign of the error signal in the PDH loop, so I put a phase shifter (a Pomona box with a 23 uF capacitor) right before the LO input of the PDH box (on the model of the X arm).
Tomorrow I will put more details about the power budget and the phase shifter transfer function.
What I did:
1. Followed the same procedure to enable ALS (http://nodus.ligo.caltech.edu:8080/40m/8703)
2. Enabling ALS servo stabilized the arm fluctuation and the beat frequency.
3. Beat frequency sweep was done (with ALS servo enabled) by changing offset C1:ALS-BEATX_FINE_OFFSET_OFFSET in steps.
The plots, with a log y axis