I've also been noticing that the IMC Autolocker scripts are running rather sluggishly on Megatron recently. Some evidence - on Feb 11 2019, the time between the mcup script starting and finishing is ~10 seconds (I don't post the raw log output here to keep the elog short). However, post upgrade, the mean time is more like ~45-50 seconds. Rana mentioned he didn't install any of the modern LIGO software tools post upgrade, so maybe we are using some ancient EPICS binaries. I suspect the cron job for the burt snapshot is also just timing out due to the high latency in channel access. Rana is doing the software install on the new rossa, and once he verifies things are working, we will try implementing the same solution on megatron. The machine is an old Sun Microsystems one, but the system diagnostics don't signal any CPU timeouts or memory overflows, so I'm thinking the problem is software related...
The burt snapshotting is still not so reliable - for whatever reason, the number of snapshot files that actually get written looks random. For example, the 14:19 backup today got all the snaps, but 15:19 did not. There are no obvious red flags in either the cron job logs or the autoburt log files. I also don't see any clues when I run the script in a shell. It'll be good if someone can take a look at this.
There were a bunch of medm processes stalled on megatron (connected with screenshot taking). To see if they were interfering with the other scripts, I killed all of the medm processes, and commented out the line in the crontab that runs the screenshots every 10 mins. Let's see if this improves stability.
The small optical bench (next to the MC-2 Chamber and the tool box tower) has been cleared of the misc. object previously on it, cleaned, and leveled (after much calibration X___X).
PLEASE, PLEASE, PLEASE do NOT MOVE OR HIT THE TABLE! It was incredibly painful to level.
This is how leveling the table made me feel...
VERY SAD...so do not move please!
The shaker has already been moved to the table and the amplifier for my shaking experiment is located behind the table (not on the table, as to prevent scratching).
Modulation resonator box is removed and the modulation depth is small right now.
I have broke the BNC connector on the modulation resonator box. The connector was attached by the screw inside very loosely and when we connect and disconnect the BNC cables from outside, extra force was applied to the cable inside and it was broke. It is being fix by Kiwamu and will be back in a bit.
Resonator box and the modulations are back now. But the modulation depth seems to be a bit smaller than yesterday, looking at the optical spectrum analyser.
I have broke the BNC connector on the modulation resonator box. The connector was attached by the screw inside very loosely and when we connect and disconnect the BNC cables from outside, extra force was applied to the cable inside and it was broke. It is being fix by Kiwamu and will be back in a bit
[Jenne, Diego, EricQ]
We did a series of small things that may have helped with the locking, although we didn't actually get anywhere closer in CARM offset.
The UGF Servo medm page has been updated to reflect the last changes, namely the return of the sum of squares and the disappearance of Test3.
I made some small edits to the LSC screen.
* When I added columns for the new AS110 PD, I had forgotten to make the Trigger matrix and Power Normalization matrix icons on the screen bigger, so we weren't seeing the last 2 columns in the overview screen.
* I added "show if not zero" oscillator icons to the Sensing Matrix part of the LSC overview screen, so that it's easier at a glance to see that there is an oscillator on.
[Ian, Paco, JC]
There is a strange smell in the 40m. It smells like a chemically burning smell maybe like a shorted component. I went around with the IR camera to see if anything was unusually hot but I didn't see anything. The smell seems to be concentrated at the vertex and down the y-arm
Facilities just came by and cleaned the smoke detector that is above Steve's desk. It's next to an air vent, so I guess it collects dust more than a "typical" smoke detector.
We've run into a problem with our attempts to get the LCS control back up and running.
As reported previously, the Dolphin fiber connection between c1lsc and c1sus appears to be dead. Since we have no replacement fiber, the solution was to move the c1lsc machine in to the 1X4 rack, which would allow us to use one of the many available short Dolphin cables, and then use a long fiber PCIe extension cable to connect c1lsc to it's IO chassis. However, the long PCIe extension cable we got from Downs does not appear to be working with our setup. We tested the cable with c1sus, and it does not seem to work.
We've run out of options today. Tomorrow we're going to head back to Downs to see if we can find a cable that at least works with the test-stand setup they have there.
The IRAF software from the National Optical Astronomy Observatory has been installed locally on Donatella(for testing) following the instructions listed here at http://www.astronomy.ohio-state.edu/~khan/iraf/iraf_step_by_step_installation_64bit
This is a step towards "aperture photometry" and would help identify point scatterers in the images of the test masses.
I will be testing this software, in particular, the use of DAOPHOT and if it seems to work out, we may install it on the shared directory.
Hope this isn't an inconvenience.
I remade another soldered circuit, adding extra 100uF electrolytic bypass capacitors at the input and output of the voltage regulator and ensuring that every grounded component now has its own path to ground rather than going through other elements. This circuit now seems to be working just like the solderless circuit. Attached is the transfer function of the soldered circuit, which matches with the result from the solderless circuit.
Here are both on the same figure- they are about overlapping but are slightly different if you zoom in enough.
I have also attached a new version of the circuit schematic to reflect the changes and to make the physical layout more clear.
My next step for these last few days this summer will be designing a PCB using Altium. I've emailed Varun about how to use Altium on the iMac but he hasn't responded. If anyone else knows how to use the software, please let me know.
On February 5, 2020, the Dell engineering workstation located in the 40M lab, was replaced with a newer Engineering workstation, per a request from Koji . The new workstation should perform a good deal better over the older unit. It has more cores, more memory and a better video card. Since this unit is being used by the 40M group, the Comsol s/w pkg. was also installed on the unit.
During the computer swap, Koji had a problem with a print job and it was discovered the bottom tray of the HP5550 printer was broken. The broken tray was replaced from another unit that was being disposed of.
Rendered the SOS assembly (D960001) with correct materials and all and it looks very nice. Will extend this to the building cad later.
I brought one CPU (Dell T3500) and one 28" monitor from Mike Pedraza's office in Downs to the 40m. It is on Steve's desk right now, pending setup. The machine already has Solidworks and Altium installed on it, so we can set it up at our leisure. The login credentials are pasted on the CPU with a post-it should anyone wish to set it up.
The cause of the decrease was found and the problem was solved. We found this entry, which says
Yoich> We opened the MOPA box and installed a mirror to direct a picked off NPRO beam to the outside of the box through an unused hole.
Yoich> We set up a lens and a PD outside of the MOPA box to receive this beam. The output from the PD is connected to the 126MON cable.
We went to the PSL table and found the dc power cable for 126MOPA_AMPMON was clipping the 126MON beam.
We also made a cable stay with a pole and a cable tie.
After the work, 126MON went up to 161 which was the value we saw last night.
We also found that the cause of the AMPMON signal change by the DAQ connection, mentioned in this entry:
Jenne> 6. We teed off of the AMPMON photodiode so that we could see the DC values on a DMM.
Jenne> When we used a T to connect both the DMM and the regular DAQ cable, the DMM read
Jenne> a value a factor of 2 smaller than when the DMM was connected directly to the PD.
We found a 30dB attenuator is connected after the PD. It explains missing factor of 2.
Steve pointed this out to me today, and Koji and I just took a look at it together: The total power coming out of the MOPA box is constant, about 2.7W. However, the NPRO power (as measured by 126MOPA_126MON) has decreased from where we left it last night. It's an exponential decay, and Koji and I aren't sure what is causing it. This may be some misalignment on the PD which actually measures 126MON or something though, because 126MOPA_LMON, which measures the NPRO power inside the NPRO box (that's how it looks on the MEDM screen at least...) has stayed constant. I'm hesitant to be sure that it's a misalignment issue since the decay is gradual, rather than a jump.
Koji and I are going to keep an eye on the 126MON value. Perhaps on Monday we'll take a look at maybe aligning the beam onto this PD, and look at the impedance of both this PD, and the AMPMON PD to see why the reading on the DMM changed last night when we had the DAQ cable T-ed in, and not T-ed in.
While my checks of the AO signal path have thrown up some unanswered questions, I don't think there's any evidence in those measurements to suggest the AO crossover can't be realized. Thinking about it today though - I was wondering if it could be that the IN1 gain slider of the CM board is configured optimally. Looking back at some data, when the ALS CARM offset is zeroed, the CM_SLOW digitized data has a peak-to-peak range of ~200 cts. This is paltry. One possibility is that as I am upping the AO path gain, I'm simply injecting the electronics noise of the CM board into the IMC error point. I'd say it is safe to up the IN2 gain by 20dB to -12 dB, in which case the peak-to-peak would be ~2000 cts, still only 10% of the ADC range. It'll be straightforward to re-scale the CARM_B loop gain to account for this. Let's see if this helps.
I'd also like to measure the spectrum of the REFL11_I signal in a few different states. I think I should be able to do this using the OUT2 of the CM servo board. These are the things to try tonight:
The other day, Jenne and I were comparing my MIST simulation to her Optickle simulation for the CARM transfer functions I posted some days ago. She told me that the arms are not exactly where they should be for the whole "PRC length tuning to account for sideband reflection phase off resonant cavity" deal.
Specifically, as in the wiki (but with newer modulation frequencies), I calculated the ideal arm length to be 37.795 m some time ago, when doing PRC length simulations, and Jenne has told me that the X arm is more like 37.6m, and Y is 37.9. So, I updated my simulations, and found the following:
This does weird things to the f2 sideband buildup on resonance in the PRFPMI configuration:
(POP is way huger than than the TR's, because the POP pd's are artificially "inside" the cavity, whereas TRX/Y is actually transmitted through an ETM)
This is not necessarily directly something to worry about, but I think the following may be. It looks like this arm length mismatch actually causes the PRCL demodulation phase in REFL 165 to change dramatically with the CARM offset. (REFL33 seems fine, though. 5 degrees causes less than a 1% effective gain change.)
My simulations don't include any signal recycling yet, so I don't have anything to show if there is a similar effect for SRCL, but it wouldn't surprise me...
Koji and I taked about cleaning up some of the flaky cable situation on the PSL table a while ago. The changes were implemented and are documented in Attachment #1. Now the Pomona box between the Thorlabs HV Driver and the NPRO head is sitting on the PSL table (sandwiched between some teflon pieces I found in cabinet S4 along the south arm), and the cables between these two devices are better strain relieved. I turned off the Thorlabs HV supply while working on the PMC table. The IMC could be locked after this work. Probably won't solve the long standing FSS mysteries but probably can't hurt.
Unrelated to this work: I also removed a Bias tee that was just hanging out on top of the FSS electronics, which was used for the modeSpec project.
Kevin was working on characterizing all of our RF photodiodes for the upgrade, and he discovered that REFL11 didn't work, as described in elog 3890. Rana was working on fixing it, but then he went off to Japan.
I visually inspected the components inside the RF cage on the REFL 11 circuit board inside the PD. Most of them were okay, but the connection between L5 and C33 (the big tunable inductor and the next capacitor in the path) was totally flaky. the leg of the inductor had been soldered directly to the trace on the PCB, and the inductor was a little bit tipped over, and pulling the trace off the board. I wiggled it a little while trying to see what was going on, and the trace broke. Since there is nothing going on between L5 and C33, just the trace, I used a piece of resistor lead to attach the two. The connection now seems very robust. I'm a little worried about the connection between the inductor and the board on the other side, but I can't see it since it's under the inductor itself.
Also, the soldering of L4 (a standard surface mount component type body) to the board seemed totally shoddy. I was desoldering the first side, and the whole inductor popped off. It was clear that the inductor was making a physical connection to the board, but not a nice solid electrical connection. So I resoldered it on. (On Alberto's schematics, it is listed as a 633nH inductor. I can't find any of this value, so I just put the same one back on. The best I could do to confirm the component was still okay was measure its resistance, and compare that to a similar inductor of a similar value. It seemed okay.)
After that I powered up the PD, and took an electrical transfer function, just to have a look-see. It seems kind of okay, although the resonance seems to be closer to 13MHz than 11MHz.
Since we would like to remove the capacitor that is in parallel with the diode itself, which will then change all of the resonant conditions on other components, I didn't worry too much about the resonant peak for tonight. We're going to have to look in on this though.
Also, I'm leaving the optical check-out for Kevin, so he will let us know if I magically fixed the PD, or if it needs some more work.
Photos of the circuit board (mostly Alberto's mods) before and after I fitzed with it are on Picasa
More testing. Probably more fixing.
Earlier today, I did some simulations that suggested that PRC lengths on the order of a cm from our current estimated one could result in degenerate PRCL and MICH signals in REFL165 at 3nm CARM offset. I attempted more demod-angle derived cavity PRC length measurements with REFL11 and REFL55, but they weren't consistent with each other...
In any case, adding dual recycling, even with a SRC length off by 1cm in either direction, doesn't seem to exhibit the same possibility, so I spent some time tonight seeing if I could make any progress towards DRMI locking.
I was able to lock SRY using AS55 in a very similar manner to PRY, after adjusting the AS55 demod angle to get the error signal entirely in I. I used this configuration to align the SRM to the previously aligned BS and ITMY. Oddly, I was not able to do anything with SRX as I had hoped; the error signal looks very strange, looking more like abs(error signal).
I then was able to lock the SRMI on AS55 I & Q, the settings have been saved in the IFO configure screen. I've used AS55Q for PRMI locking with a gain of -0.2, so I started with that; the final gain ended up being -0.6. PRMI/PRY gain for prcl is something like 0.01, so since I used a gain of 2 for locking SRX, I started the SRCL gain around 0.02, the final gain ended up being -0.03. I basically just guessed a sign for AS110 triggering. Once I lucked upon a rough lock, I excited the PRM to tune the AS55 angle a few degrees; it was luckily quite close already from the SRY adjustment. AS110 needed a bigger adjustment to get the power into I. (AS55: -40.25->-82.25, AS110: 145->58, but I put AS55 back for PRMI)
I briefly tried locking the DRMI, but I was really just shooting in the dark. I went back and measured various sensing amplitudes/angles in SRMI and PRMI configurations; I'm hoping that I may be able to simulate the right gains/angles for eventual DRMI locking.
As Koji measured the other day: MICH and PRCL seem very degenerate in the 3f REFL PDs.
I'm using this as a motivation to do some simulation in MIST and try to understand the best way to implement the 3F locking scheme. Hopefully my thinking below isn't nonsense...
First, I modeled the PRC with no arm cavities and the estimated cavity length I got with the PRM kick measurement, and looked at the REFL sensing matrix.
This agrees with the observed degeneracy. I then modeled the case of the PRC length that gives coincident SB resonance, again with no arm cavities.
Now there is good separation in REFL165. (REFL33 still looks pretty degenerate, however). This raised the question, "What does the angle between MICH and PRCL in REFL165 do as a function of macroscopic PRC length?"
To me, this implies that locking the PRC on 3F from scratch won't be simple. However, the whole point of the PRC length choice is to have coincident SB resonance when the arms are resonating.
So: even if we're not spot on, we should be relatively close to the PRC length where having arms resonant gives us simultaneously resonant upper and lower sidebands, where MICH and PRCL should be orthogonal-ish. I.e. building up a little bit of IR power in the arms may start to break the degeneracy, perhaps allowing us to switch from 1F to 3F locking, and then continue reducing the CARM offset.
So, I ultimately want to model the effect of arm power buildup on the angle between MICH and PRCL in the 3f PDs. This is what I'm currently working on.
So far, I have reproduced some of the RC modeling results on the wiki to make sure I model the arms correctly. (I get 37.7949 m as the ideal arm length for a modulation freq of 11.066134 MHz vs. 37.7974m for 11.065399 MHz as stated on the wiki). Next, I will confirm the desired PRC length that accounts for the arms, and then look at the MICH vs PRCL angle in the REFL PDs as a function of arm power or detuning.
Koji noted oddities in the sensing matrix results I had gotten; namely that the plots showed REFL33 not changing at all, when we know for a fact that this should not be the case.
Gabriele lent his eyes to my code, and came up with the idea that the modulation depths I was using were maybe not ideal (.1 for both 11 and 55). This affects REFL33 in that it is not simply Carrier * 33Mhz + 11Mhz * -22Mhz but also 22MHz * 55MHz, etc.
I got more realistic values from Jenne (0.19 for 11MHz and .26 for 55Mhz) and re-ran the code, with more realistic results. The behavior for 165 has remained the same, but the other signals are more well behaved.
Moral of the story: the modulation depths affect the 3f signals in a complicated way.
Locked on the sideband, the MICH / PRCL angle is much less sensitive to the PRC length, and shouldn't in fact be as degenerate as we've seen in reality.
So, my simulations no longer provide any reason for the 3F signals to be so degenerate.
I moseyed into the control room this morning, to find ITMX and ITMY both with their watchdogs tripped. ITMY (new convention) wouldn't damp. Koji discovered that there was a sign flip in 2 of the sensors. A set of reboots of c1susvme1&2 fixed the problem.
A side note: For the ETMs, the OSEM sensor readouts are gigantic (~20,000), whereas for the similar channels on all other optics, the readouts are on the order of 1. After some looking around, it seems that this is just the way things have been (for at least 100 days), and the filters in the SUSPOS and other SUS filter banks have a high pass filter to take care of this. It's weird, but it seems to be the way it is, and the ETMs damp, so it's all good.
The pumpdown seems to be progressing smoothly, so I think we are going to stick with the plan decided on Wednesday, and vent the IFO on Monday at 8am. I decided to do some checks of the IFO alignment.
I turned on the PSL again (so goggles are advisable again inside the VEA until this work is done), re-locked the PMC, and opened the PSL shutter into the vacuum (still low power 100 mW beam going into vacuum). The IMC alignment required minor tweaking, but I recovered ~1300 cts transmission which is what it was --> so we didn't macroscopically change the input pointing into the IMC while working on the IOO table.
Centering the ITMY oplev spot, there is a spot on the AS camera roughly centered on the control room monitor, so the TT pointing must also be pretty close.
Then I centered the ITMY oplev spot to check how well-aligned or otherwise the Michelson was - the BS has no Oplev so there was considerable angular motion of the Michelson spot, but it looked like on average, it was swinging around through a well aligned place. I saved the slow bias voltages for the ITMs and BS in this config.
Then I re-aligned ETMX and checked the green transmission - it was okay, ~0.3, and I was able to increase it to ~0.4 using the EX green PZT mirrors. So far so good.
Finally, I tried to lock the X-arm on IR - after zeroing the offsets on the transmission QPD, there seems to be a few flashes as the cavity swings through resonances, but no discernible PDH error signal. Moreover the input pointing of the IR into the X arm is controlled by the BS which is swinging around all over the place right now, so perhaps locking is hopeless, but the overall alignment of the IFO seems not too bad. Once ETMY is cleaned and put back in place, perhaps the Y arm can be locked.
I shuttered the PSL and inserted a manual beam block, and also turned off the EX laser so that we can vent on Monday without laser goggles.
*Not directly related to this work: we still have to implement the vacuum interlock condition that closes the PSL shutter in the event of a vacuum failure. It's probably fine now while the PSL power is attenuated, but once we have the high power beam going in, it'd be a good to revert to the old standard.
These boxes were moved from the 40m hallway to the inside of the VEA so that we have some space to walk around. You can find some pictures here.
We discovered to our great dismay that several important channels (namely C1:IOO-MC_L, but also everything on c1susvme2) are not being recorded, and haven't been since May 17th. This corresponds to the same day that some other upgrade computers were installed. Coincidence?
We've rebooted pretty much every FE computer and the FrameBuilder and DAQ_CONTROL approximately 18 times each (plus or minus some number). No matter what we do, or what channels we comment out of the C1SUS2.ini file, we get a Status on the DAQ_Detail screen for c1susvme2 of 0x1000. Except sometimes it is 0x2000. Anyhow, it's bad, and we can't make it good again.
I have emailed Joe about fixing this (with some assistance from Alberto, since we all know how much he likes doing the Nuclear Reboot option for the computers :)
The fundamental problem is way back when I built the new LSC model using "lsc" as the name instead of something like "tst", I forgot to go to the current frame builder master file (/cvs/cds/caltech/chans/daq/master) and comment out the C1LSC.ini line. Initially there was no conflict with c1susvme, because the initially was dcu_id 13. The dcu_id was eventually changed to 10 from 13 , and thats when it conflicted with the c1susvme2 dcu_id which was also 10. I checked it against wiki edits to my dcu_id list page and I apparently updated the list on May 20th when it changed from 13 to 10, so the time frame fits. Apparently it was previously conflicting with C0GDS.ini or C1EXC.ini, which both seem to have dcu_id = 13 set, although the C1EXC file is all commented out. The C0GDS.ini file seems to be LSC and ASC test points only.
The solution was to comment out the C1LSC.ini file line in the /cvs/cds/caltech/chans/daq/master file and restart the framebuilder with the fixed file.
Just as I expected, since these hunuman didn't actually check MC_L after doing this stuff, MC_L was only recording ZERO. Joe and I reset and restarted c1susmve2 and then
verified (for real this time) that the channel was visible in both the Dataviewer real time display as well as in the trend.
The lesson here is that you NEVER trust that the problem has been fixed until you check for yourself. Also, we must always
specify a very precise test that must be used when we ask for help debugging some complicated software problem.
PRCL: 100cnt -> PRM 567.01Hz
Signal in demod Q ch were minimized
REFL11I -19.2deg demod I, Lockin I out (C1:CAL-SENSMAT_PRCL_REFL11_I_I_OUTPUT) 12.6 cnt
REFL33I +130.4deg 1.70cnt
REFL55I +17.0deg 2.30cnt
REFL165I -160.5deg 27.8cnt
MICH: 1000cnt -> ITMX(-1) & (ITMY +1.015 => Minimized the signal in REFL11I to obtain pure MICH)
REFL11I +0.0 REFL11Q +0.119
REFL33I +0.023 REFL33Q -0.012
REFL55I +0.023 REFL55Q -0.113
REFL165I +0.68 REFL165Q +0.038
It seems that REFL165 has almost completely degenerated PRCL and MICH.
ITMX(-1)/ITMY(+1.015) actuation was cancelled by BS (+0.16). This introduces PRCL in REFL11I. This was cancelled by PRM (-0.084)
REFL11I +0.0 REFL11Q +0.13
REFL33I -0.012 REFL33Q 0.025
REFL55I +0.041 REFL55Q -0.45
REFL165I +0.69 REFL165Q +/-0.02
Again, It seems that REFL165 has almost completely degenerated PRCL and MICH.
[Signal source] REFL11I (-19.2deg) x 0.16, OR REFL33I (+130.4deg) x 2.0, OR REFL55I (+17.0deg) x1.0, OR REFL165I (-160.5deg) x0.05
[Trigger] POP110I(-81deg) 100/10, FM trigger 35/2, delay 0.5sec FM2/3/6/9
[Servo] FM4/5 always on. G=-0.02, Limitter ON
[Output] PRM x+1.00
[Signal source] AS55Q (-5.5deg) x 1, OR REFL11Q x 0.25, OR REFL55Q x-0.06
[Trigger] POP110I 100/10, FM trigger 35/2, delay 5sec FM2/3/9
[Servo] FM4/5 always on. G=-10, Limitter ON
[Output] ITMX -1.0 / ITMY +1.0 (or +1.015), OR PRM -0.084 / BS +0.16
We made an attempt at cleaning up the phase camera setup electronics.
We have moved a portion of the electronics onto the SP table (specifically the mixer, splitters, amplifiers, and associated power). We put away a large number of cables which were unneeded, both BNC and power cables. The Innolight Mephisto power supply and one signal generator are still behind 1Y2 on top of a non-functioning VME crate. The second VME crate was put along the south arm where two other VME crates already were. We placed a fair number of BNC cables and power cords back on their cable racks or approriate storage space, so the rats nests of cables has been reduced.
We moved one power strip from plugging in beyind 1Y1, to the far side of the SP table (closer to the 1Y3 rack), and also found and plugged in another power strip (also on the far side of the SP table) and placed this underneath the SP table to be able to power the signal generator and Innolight Mephisto laser (its not plugged in currently, but we'd like to do so next week).
We found c1lsc, c1iscex, c1iscey, c1susvme, c1asc and c1sosvme are dead.
We turned off all watchdogs and turned off all lock of suspensions.
Then, I tried to reboot these machines from terminal, but I couldn't login to all of these machines.
So, we turned off and on key switches of these machines physically, and login to them to run startup scripts.
Then we turned on all watchdogs and restored all IFO.
Now they look like they are working fine.
At the suggestion of Rana and Koji, I have worked out some design parameters for a Stewart platform to be used as a vibration isolation device or as a platform for characterization of suspensions. I have made some initial guesses about the following design requirements:
From these assumptions, I have worked out:
The combination of high force, high speed, and ~micron travel limits seems to point to piezoelectric actuators. PI's model P-225.80 would meet the peak push-pull force requirement, but I have not yet determined if it would meet the bandwidth requirement. Apparently, typical piezoelectric actuators can exert a greater push force than pull force; wonder if one could use an actuator with a smaller force range than the P-225.80 if the actuator is biased by compression. (Is this what is meant by a "preloaded" actuator?)
I have attached a PDF explaining how I worked out the actuator force and platform dimensions. (I'll try to dice up this PDF and put the contents in the Wiki.) I also have a plant model in MATLAB with which I have been playing around with control schemes, but I don't think that this is ready to show yet.
Here are some tasks that still remain to be done for this preliminary case study:
I'd like to ask for input principally on:
Edit: I also added a Mathematica notebook with the inverse kinematics (mapping from platform state to leg lengths) of the platform.
(* Content-type: application/vnd.wolfram.mathematica *)
(*** Wolfram Notebook File ***)
(* http://www.wolfram.com/nb *)
(* CreatedBy='Mathematica 8.0' *)
(* Internal cache information:
I've been getting a simulation going with the eventual goal of simulating CESAR-type signals for CARM. So for I've only been using MIST, though I'm still thinking about what to do for a fully time domain approach. (For example, maybe a mixture of simulink and analytical equations? We'll see how painful that gets...)
Anyways, with the parameters I have for the 40m, I've set up a simulation, where I can do things like a "static" CARM scan.
(i.e. PRMI perfectly locked. Ask what different PDs see if the arms were just statically sitting at some CARM offset)
PDH signals are there in the REFL diodes. The coupled line width here looks smaller than the ~40pm number I've heard before, so I should check my parameters. (Likely culprit, I'm using nominal R and T for the arm cavities)
I've also done the slightly more sophisticated thing of looking at the transfer function from CARM motion to different PDs, at different CARM offsets. For TRX and REFLDC, these seem to match up qualitatively to some plots that Kiwamu has done for aLIGO, with frequencies shifted by the relative arm length factor of 100. (Q's left, K's right, Y-axis on mine are W/m with 1W input the IFO)
We can also look at the PDH diodes (revised from my initial post. Had an error in my code):
That's where I've gotten so far!
A big factor in how much IFO locking activities can take place is how cooperative the IMC is.
Since the c1psl upgrade, the IMC duty cycle has definitely deteriorated. I took a measurement of the dark noise at the IMC error point with 1 Hz FFT binwidth, with all electrical connections to the IMC servo board except the Acromag and Eurocrate power disconnected. I was horrified at the prominence of 60 Hz harmonics - see Attachment #1. In the past, this kind of feature has been indicative of some error in the measurement technique - but I confirmed that the lines remain even if I unplug the GPIB box, and all combinations of floating/grounded inputs that I tried. We know for sure that there is some excess noise imprinted on the laser light post upgrade. While these lines almost certainly are not responsible for the PCdrive RMS going bonkers, surely this kind of electrical situation isn't good?
Attachment #2 shows the same information translated to frequency noise units, taking into account the complementary sensitivity function, L/(1+L) - the sum contribution of the 60 Hz peaks to the RMS is ~11.5% of the total over the entire band (c.f. 1.7 % that is expected if the noise at multiples of 60 Hz was approximately equal to the surrounding noise levels). Moreover, the measured RMS is 55 times higher than a LISO model.
How can this be fixed?
Some tests done today:
All of these tests were done with the PRMI locked with carrier resonant in the recycling cavity (i.e. sidebands rejected to REFL port). I then actuated the BS length DOF with a sine wave at 311.1 Hz, 40 cts amplitude (corresponding to ~8 pm of peak-to-peak displacement).
While it would seem from these graphs that the RIN of the LO beam at these frequencies is rather high, it is because of the ADC noise. More whitening (to be installed in the coming days) will allow us to get a better estimate, should be ~1e-6 I think.
I was just playing today, still need to setup some more screens, DTT templates etc to do more tests in a convenient way.
Now, I can think about how to commission this setup interferometrically.
I manually aligned the IMC. Spot positions are all < 1.5mm. PMC trans of ~0.74, MC2 Trans of ~15400, MC Refl ~0.4, which is better than its been for some time now.
Somehow the WFS DC offsets were off, which made it look like it was impossible to center the beam on WFS2. The script for setting these wasn't working so I fixed it, ran it. WFS and MC2 trans offsets were set, WFS are back on and have been holding MC REFL nice and low for ~3 hours.
Arms were dither aligned, wrote the offsets to SDF files. Oplevs need centering. No further daqd crashes.
The optomechanics stock in the lab was in a sad state. We have obtained the following from Thorlabs in the last two months:
I have used some of these for the ari BHD setup. The unused items are stored in the shelves that house the optomechanics ~halfway down the east arm. I'm wondering what's a good setup to document the stock of this stuff so we can always have a healthy stock of optomechanics (at least the non speciality ones like posts, spacers etc). It sucks to realize at 0000hrs that you're missing a 3mm shim or 250mm converging lens or something.
[Rana / Kiwamu]
As a part of the ALS noise budgeting we took a look at the Y end PDH setup to see if we are limited by an effect from the Amplitude Modulation (AM).
(AM transfer function)
(Y table setup needs more improvements)
What is meant by the "average response of 50 dB"? Is this dB[ RIN / Hz ] or something? Also, do you mean the average over a broad band or the average response at the chosen modulation frequency over several trials? I don't really understand what measurement was done.
I think I solved the problem (as you can probably see).
The cause was that this WYSIWYG interface for HTML is provided by an independent text editor called FCKeditor which is included in the elog. Although the elog installer has a bug and does not unzip properly the relative package. One has to do it by hand. (going to /elog/scripts/ and unzipping fckeditor.zip by hand in the same directory).