I hope you're not all tired of the STACIs noise budgets, because I have another one! Here, the main difference is my modeling of the geophone sensitivity according to a predicted physical model for the system (just a damped oscillator) instead of trying to fit it to the accelerometer motion signal with more arbitrary functions.

The result of this calibration is shown below (accel and geo signals taken for 5 minutes at the same time, in granite and foam):

The m/s/V sensitivity function I am using is g*[(w^2-2idww(0)-w(0)^2)/w^2], where g (the high freq. m/s/V sensitivity) was 2.5*10^-5 and d (damping) was set to 2.

Now, the recalculated noise plot looks like this:

The accel. specs I took from the Wilcoxon spec sheet, and the geo specs I found in https://dcc.ligo.org/public/0028/T950046/000/T950046-00.pdf, a LIGO document about the STACIS. The geo noise was measured for the STACIS geo and their pre-amp, while I was using the SR560 as the pre-amp. If anything, my noise should be lower, since the SR560 noise spec is lower than what I estimated for the STACIS geophone pre-amp, so I'm not sure about that order of magnitude difference between the experimental and expected geo noise. A sign that my noise values are at least reasonable is that the geophone noise flattens out above the geophone's resonant frequency (4.5 Hz), as Jan pointed out it should.

The sensor noise (either accel. or geo.) is the dominating signal below 1 Hz in the STACIS platform measurement, which then limits the closed loop performance at those frequencies. Since the noises I am finding are looking reasonable, I think it's fair to definitively state that accelerometers will not significantly help at low frequencies (there may be at most a factor of 2 lower noise below 1 Hz for the accel., but I need more data to say for sure).

The plan right now is to concentrate on using the STACIS as actuators, perhaps with seismometers on the ground and a feedforward signal sent into the high voltage amplifier.

I took the transfer function of the high voltage board itself (no pre-amp included) by driving the PZTs with a swept sine and measuring the accelerometer response (which I am now fairly confident is calibrated correctly). The input point was the signal IN on the extender board, but with the geophones disconnected from the pre-amp.

I took the coherence at just a few single frequencies (you can't do coherence measurements in swept sine mode on the SR785) to make sure I was really driving the PZTs, and it was near 1 (998, 999.9, etc) at the frequencies at which I drove. Without the extra notches at 1 Hz (which may be real, it's coherent there too), it looks like a 2-pole high pass filter (goes from -180 to 180 deg, approx. an f^2 dependence). This transfer function should be taken into account by the feedforward algorithm.

The current plan is to make a box with a switch that allows geophone feedback and/or external signals into the high voltage amplifier. It would act sort of like the extender card, except more compact so it could fit into the STACIS. It also would have the advantage of not having to reroute the power, since those lines from the pre-amp could all still be connected (see eLog 7118: http://nodus.ligo.caltech.edu:8080/40m/7118).

Today I worked on locking the Michelson. Here's what I did:

1. Open Data Viewer and Restore Settings /users/Templates/JenneLockingDataviewer/MICH.xml. This opens the C1:LSC-ASDC_OUT and C1:LSC-AS55_Q_ERR plots.

2. Check the LSC screen to verify that the path between the Servo Filter Modules and the SUS Ctrls are outlined in green. If not turn on the OUT button within the Filter Servo Modules, enable LSC mode, and turn on the SUS Ctrls for the BS.

3. Misalign all optics other than BS and one of ITMX and ITMY. The ITMY was already well-aligned from my work on locking the YARM, so I actually chose to misalign ITMY at first.

4. Restore BS and ITMX. Use the AS camera on the video screen as your guide when aligning ITMX.

5. Adjust pitch and yaw of ITMX until a bright, circular spot appears near the middle of the AS camera.

6. Now restore ITMY and adjust pitch and yaw until a second circular spot appears on the AS camera.

7. Adjust both ITMX and ITMY until both bright spots occupy the same location. If the spots remain bright when they are in the same location you are locking onto a bright fringe actually, and need to flip the sign of the gain on the MICH servo filter modules. I had to do this today in fact, as discussed in ELOG 7145.

8. If the sign is correct, the two beams should interfere destructively and the formerly bright spots will form a comparatively dark spot. The shape of the spot will likely be two bright lobes separated by a dark middle.

9. C1:LSC-ASDC_OUT should be a roughly flat signal, and the goal now is to minimize the magnitude of this signal. The smaller this signal, the darker the AS camera should look. Decent target values for C1:LSC-ASDC_OUT are around 0.10 to 0.05.

Once I did this, I made measurements by exciting C1:SUS-ITMY_LSC_EXC and measuring with C1:LSC-AS55_Q_ERR. I ran a logarithmic swept sine response from 1 to 1000 Hz again, with an envelope amplitude dependence. Again I looked at the measured transfer function and coherence. I was able to get good coherence, but it was somewhat erratic in that it dipped low at high frequency multiple times.

 Using Guralp, STS-2 and Trillium I compared Gur and STS-2 self-noise assuming that Trillium noise is not worse then STS-2 noise.

Interesting that STS-2 (or Trillium if its noise is worse) noise is not too much better then Guralp noise.

Sim_Plant going okay. Adding seismic noise tomorrow - we'll see what happens. The gain is still semi-off, but I know how to fix it - its just nice to have it gained up while I play with noise.

P.S. JAMIE DO YOU NOTICE HOW PRETTY MY GRAPH IS?

Developed some seismic noise. I adapted the seismic noise filters we used for the MC model way back when.  They looked questionable to begin with, but I added some poles/zeroes to make it more accurate (see Attached).

STS-2 - end of X arm

GUR 2 - isolation box

TRILLIUM - 1Y3 (DC power supply uses 1Y3 AC power, please do not close the door completely)

GUR 1 - end of Y arm

Now we have several "triangular seismic antennas". Different configurations can be chosen to compare the results.

Caltech security called me at 1am Sunday. Control room emergency exit door was found unlocked!

It is your responsibility to lock door if you unlocked it !

I unlocked the door on Tuesday in order to move the red cart.
After that I confirmed that the door was locked.

[Masha, Sasha]

Sorry to spam the e-log, but did someone come knock loudly on the emergency exit door a few moments ago? It gave Sasha and I quite a fright, and we are rather worried.

 Probably, security. You can call 5555 and ask them. Otherwise you can ask them to come and check everything.

You mean 5000?

The PD (pda255) at the AP table, close to the MC refl , which Steve mentioned to be not in use, has been removed from the table for testing.

I'm proposing larger optical tables at the ends to avoid the existing overcrowding. This would allow the initial pointing and optical level beams to set up correctly.

The existing table is 4 x 2 would be replaced by 4' x 3'   We would lose only ~3" space  toward exist door.

I'm working on the new ACRYLIC TABLE COVER for each end that will cost around $4k ea.  The new cover should fit the larger table.

Let me know what you think.

We were not able to open up any test points in the revived c1spx model (dcuid 61).

Looking at the GDS_TP screen we found that every test point was being held open (C1:FEC-61_GDS_MON_?).  Tried closing all test points, awg and otherwise, with the diag comnand line (diag -l), but it would crash when we attempted to look at the test points for node 61.

Rebuild, install, restart of the model had no affect.  As soon as awgtpman came back up all the testpoints were full again.

I called Alex and he said he had seen this issue before as a problem with the mbuf kernel module.  Somehow the mbuf module was holding those memory locations open and not freeing them.

He suggested we reboot the machine or restart mbuf.  I used the following procedure to restart mbuf:

• log into c1iscex as controls
• sudo /etc/init.d/monit stop (needed so that monit doesn't auto-restart the awgtpman processes)
• rtcds stop all
• sudo /etc/init.d/mx_stream stop
• sudo rmmod mbuf
• sudo modprobe mbuf
• sudo /etc/init.d/mx_stream start
• sudo /etc/init.d/monit start
• rtcds start all

Once this was done, all the test points were cleared.

Alex seems to think this issue is fixed in a newer version of mbuf.  I should probably rebuild and install the updated mbuf kernel module at some point soon to prevent this happening again.

Unfortunately this isn't the end of the story, though.  While the test points were cleared, the channels were still not available from c1spx.

I looked in the framebuilder logs to see if I could see anything suspicious.  Grep'ing for the DCUID (61), I found something that looked a little problematic:

...
GDS server NODE=25 HOST=c1iscex DCUID=61
GDS server NODE=28 HOST=c1ioo DCUID=28
GDS server NODE=33 HOST=c1ioo DCUID=33
GDS server NODE=34 HOST=c1ioo DCUID=34
GDS server NODE=36 HOST=c1sus DCUID=36
GDS server NODE=38 HOST=c1sus DCUID=38
GDS server NODE=39 HOST=c1sus DCUID=39
GDS server NODE=40 HOST=c1lsc DCUID=40
GDS server NODE=42 HOST=c1lsc DCUID=42
GDS server NODE=45 HOST=c1iscex DCUID=45
GDS server NODE=46 HOST=c1iscey DCUID=46
GDS server NODE=47 HOST=c1iscey DCUID=47
GDS server NODE=48 HOST=c1lsc DCUID=48
GDS server NODE=50 HOST=c1lsc DCUID=50
GDS server NODE=60 HOST=c1lsc DCUID=60
GDS server NODE=61 HOST=c1iscex DCUID=61
...

Note that two nodes, 25 and 61, are associated with the same dcuid.  25 was the old dcuid of c1spx, before I renumbered it.  I tracked this down to the target/gds/param/testpoint.par file which had the following:

[C-node25]
hostname=c1iscex
system=c1spx
...
[C-node61]
hostname=c1iscex
system=c1spx

It appears that this file is just amended with new dcuids, so dcuid changes can show up in duplicate.  I removed the offending old stanza and tried restarting fb again...

Unfortunately this didn't fix the issue either.  We're still not seeing any channels for c1spx.

So I was wrong, the channels are showing up.  I had forgotten that they are showing up under C1SUP, not C1SPX.

I'm not sure I see the motivation.  The tables are a little tight, but not that much.  If the issue is the incidence angle of the IP and OPLEV beams, then can't we solve that just by moving the table closer to the viewport?

The overcrowding alone doesn't seem bad enough to justify replacing the tables.

I tried to make ringdown measurements at the IMC using the DC falling edge as the trigger. Input to the MC was switched off by changing the polarity of the MC servo. But it does not seem to give the needed data as there seem to be several DC falling edges as soon as the polarity is switched. We should think about a better trigger or try to setup data recording from the oscilloscope seamlessly.

Also an ethernet cable has been connected to the router from the oscilloscope at the MC trans, but has not been set up to record data yet.

I moved the c1sup simplant model to the c1lsc machine, where there was one remaining available processor.  This requires changing a bunch of IPC routing in the c1sus and c1lsp models.  I have rebuilt and installed the models, and have restarted c1sup, but have not restarted c1sus and c1lsp since they're currently in use.  I'll restart them first thing tomorrow.

In eLog 7148 (http://nodus.ligo.caltech.edu:8080/40m/7148), Koji pointed out that the op-amp and SR560 noise values (which I took from specs and then multiplied by the geophone calibration factor to get m/s/rtHz) were waaay too low. My error was an extra multiplication factor in the plotting script.

The other change was recalculating the ADC noise by splitting a signal into two ADC channels and subtracting the time series (then taking the PSD and converting to m/s/rtHz). It compares well to the value I got by terminating the ADC channels, which was the ADC noise line in my last eLog.

Both these changes are included in the below plot:

Simplant for ETMX was left on, so I didn't have control of ETMX.  Not cool.  The IFO should be left in it's 'regular' state (all optics restored to saved alignments, no simplant, LSC/ALS/ASS loops off) if you're not actively working on it.

What this did point out, however, is that we need a big ol' indicator on the IFO_ALIGN / LSC / Watchdog / Overview screens to indicate that simplant is on for a particular optic, or whatever simplant might be controlling that takes away 'regular' control.  I probably would have continued being frustrated and confused for a lot longer if Eric didn't mention that simplant could have been left on.  Thanks Eric!

Symptoms, which perhaps would have eventually pointed me to simplant, were that there was some weird moving beam on the AS camera that was flashing fabry-perot fringes, and the POX signal looked like junk. After some looking around, I noticed that ETMX, while it claimed to have all the damping loops on, and the oplev on, was swinging a lot (rms levels of 4 - 7, rather than the usual < 2 ).  I said something out loud, and Eric suggested looking at Simplant.  After putting Simplant back to Reality, things are back to normal.

I'm trying to lock / align the Xarm, and POX 11 I looks funny sometimes.

I attach 2 screenshots so you can see what I mean.  I'm leaving them uncropped so that you can see the only thing that has changed is the LSC enable / disable button. 

The situation:

PRM, SRM, ITMY, ETMY all misaligned.  BS, ITMX, ETMX aligned so that most of the time I can't lock better than 04, bad in yaw, but very occasionally I'll get lucky and catch a 00.  When the LSC enable switch is ON (2nd attachment), the POX signal (green trace in dataviewer in both attachments) looks almost square-ish, and definitely funny.  It doesn't seem to correspond directly to flashing in the cavity (red trace in dataviewer in both attachments).  However when I disable the LSC, POX goes back to looking normal - 1st attachment.  Right around -5 seconds in the 1st attachment, I disabled the LSC.

I don't really know what this means.

 The alignment was way off. We moved the PZT, the BS, and the x arm to get it to lock. Along the way we noticed that giving the ETM and POS offsets makes it tilt a lot. The DC coil balancing is no good at all.

After locking, we tuned up the X arm filters in the LSC and activated the filter module triggers.  I would attach a screenshot of the trigger screen, but sadly it has no snapshot button on it.

WE changed the integrator into a double integrator with a complex zero pair. We also replaced the 1:50 boost with a 2nd order complex pole:zero pair. And added a 18 Hz RG. These were all set by looking at the error point spectra and minimizing the RMS. Hopefully, this kind of work will all be obsolete once we get the optimal feedback code. For now, the arm is very stable - we're leaving it locked overnight since the filter triggering seems to work well.

The loop kept oscillating, so we turned the xarm gain down from the 0.3 that we found it at down to 0.045. We measured the loop gain using our old xarm loopgain DTT template (which is in the Templates directory, not in /users/IAmAnAmateur/secret/secret/bozo/). It shows that we are missing ~20 deg of phase at the peak of the phase bubble compared to the old days. We guess that its because of the downsample/upsample digital AA filters which we now have in addition to the 7kHz hardware AA/AI which we still have from the pre-upgrade times). We (Jamie) have to think about how to rationalize this: we cannot survive with double AA/AI.

Another big hindrance in the lock acquisition is that the whitening filters were on. Because the WG is set to 45 dB, the ADCs are getting saturated when the flashes are large. We should have the whitening filters switch after acquiring lock.

Also, why are all the camera views of the ITMs and ETMs different? Steve, please go back and make them all the same (angles, aperture, lenses, etc.). Without them being the same, we cannot compare them.

 I have found the video capture scripts in Yuta's personal directory. This is illegal, of course. All useful scripts (even when in development) go into the shared scripts directory. As a punishment, I have added some nasty typos to a couple of his other scripts and then backdated the timestamps so that he cannot find it easily.

 Also, I fixed the "mcup" script. After the ringdown people inserted the pickoff for MC2 trans, no one adjusted the thresholds in the MC autolocker. I've fixed mcup to trigger at 7000 cts. This should be changed back if the pickoff is removed someday. MC WFS now coming on.

Yoichi, Rana

Here is the open loop gain of the XARM loop.

The reference is from the pre-upgrade era. We get the extra phase delay because we have two anti-aliasing filters. One is the hardware filter at about 7kHz for 16kHz sampling. This filter should have been replaced to the one for 64kHz sampling but it has not yet happened. The second one is the software anti-aliasing filter applied when down sampling from 64kHz to 16kHz. So we have double AA filters, which are the culprits for the extra phase delay.

We should either replace the hardware AA filter to the 64kHz one (preferred way), or change the software AA filter to a less aggressive one (easier temporary fix).

Yoichi, Rana

Here is the noise spectrum of the X-arm error signal along with the TRX DC power fluctuations.

The spectra were taken while the whitening filters for POX11 were OFF.

EDIT (Integrity Fairy): Shall we assume these units are "Intergalactic translational qubits/sqrt(Hz)"?

The janitor accidentally hit the laser emergency kill switch at room 103  entry door. It did shut down the PSL laser. The laser was turned back on.

When signals are transmitted between the models running at different rates, no AI or AA filters are automatically applied. We need to fix our models.

Rolf and Alex came over this morning to see if they could help debug some issues we have been seeing with IPC transmission between the c1sus and c1lsc machines.

c1oaf, which runs on c1lsc, sees a lot of transmission errors on it's dolphin receivers from c1rfm, which runs on c1sus.  Their speculation is that c1rfm is trying to process too many channels, and it's not able to read off all the RFM channels and retransmit them over dolphin to c1lsc before the end of cycle.  To test this they turned off all RFM reads on c1rfm and the dolphin receiver errors on c1lsc all went away.  We ran into other problems before I had a chance to pester them about what the take-away is here.  We might just need to reduce the load on c1rfm, maybe by introducing a c1rfm2?

We then tried to debug an issue in the c1sus machine where models would occasionally run slow for a cycle, or run slow when a different model on the machine was loaded or unloaded.  The suspect was BIOS settings.  Unfortunately, we ran into trouble when we tried to tweak the BIOS setting on c1sus.  We found that all the serial/COM ports were on, which is usually a big no-no for the RTS (the interrupts cause many cycle delays).  However, turning off the COM ports prevented the machine from booting at all.  This was a big mystery.  The machine seemed to be acting flaky in general as well, since the boot (pre-kernel) would hang in various places after different reboots.  Alex went to grab us a spare machine that we're going to try swapping out this afternoon.

This is known, but we just haven't fully groked it yet.  We need to look closely at every place we have IPCs between models running at different rates.  The sender has no information about receivers, so it can't reasonably do anything to pre-filter the signal on it's own.

So for transmission from:

• faster -> slower models: add anti-aliasing on the sender side
• slower -> faster models: add anti-imaging on the receiver side
  

 A huge data flow goes from PEM to OAF through RFM. I think we need to make PEM and OAF run on the same machine and transmit signals through the shared memory.

 *sigh* This is one of those things that I meant to take care of months ago, but haven't yet.  I agree that it needs doing.  It's been on my whiteboard to-do list for a long time now.  Bad Jenne for not taking care of it.

 I optimized the TM views with illuminator light on quad1  It actually looks better there.

I'll post a dark-  OSEM light only in jpg tomorrow.  ETMY camera is malfunctioning in dark condition now.

Steve pointed out to me (this is not in his original elog, although you can see it in the photo if you look closely), that we can't really move the table legs any closer to the chamber.  We have maybe 3" of clearance between the table leg and the blue support tube that supports the bottom of the stack.  Therefore, we can't just

So Steve's proposal is to leave the legs exactly where they are, and just put a larger table on those legs.  This leaves 9" unsupported on the chamber side, and 3" unsupported on the far side.  The tables are 4" thick. 

Steve also mentions that we will lose 1.5" on all 4 sides of the table, with the new acrylic boxes, so we'll be down to 1'9" unless we get the larger table, in which case we'd have 2'9", and 3'9" on the long direction.

I would like to see a sketch of the end tables, so we can see if 1'9" x 3'9" is enough.  Manasa is working on a new end table layout in parallel to the ringdown stuff.  If we're actually concerned about the input angle of the oplevs, then to fix that we need to either get the bigger table and hang it off the edge of the legs, or perhaps as Dmass suggested, get a "doggy cone collar", and give ourselves a larger opening angle of access to the viewport, from the current table location.

I went down to the Xend table to look at it to understand Steve's proposal, and I noticed that the doubling crystal's heater's cable is mushed between the table's edge and the black table cover wall.  This made me sad, so I disabled the heater, turned it off, then unplugged the cable from the back of the controller.  I tried to re-route the cable through the hole in the black table cover wall, but going that way the cable is ~1 foot too short.  So I put it back the way it was, but used a totally hacky solution to prevent the cable from being mushed.  I put a dog clamp right at the edge of the table so it is pushing on the table cover wall a little bit, to give the cable space to get out.  This is very mickey mouse, and kind of lame.  But we either need to make a cable extension, or somehow get the heater controller to sit much, much higher under the table.

I plugged the heater controller back in, and turned it back on to the same setpoint that it was at (I think 37.5C).  It's probably warm by now, but when I turned it back on, the heater's actual temp was 33C.

I added an indicator to the watch dog screen so that a little "SP" icon appears whenever the SimPlant is on. Since we only have one simplant (ETMX), only ETMX has the simPlant indicator. However, since assymetry is ugly, I moved all of the OL icons over so that they're in a line and so that there is room for future SP icons.

I also fixed the link to the Watchdogs on the main SUS screens (it was dead, but now it is ALIVE).

Rolf and Alex came back over with a replacement machine for c1sus.   We removed the old machine, removed it's timing, dolphin, and PCIe extension cards and put them in the new machine.  We then installed the new machine and booted it and it came up fine.  The BIOS in this machine is slightly different, and it wasn't having the same failure-to-boot-with-no-COM issue that the previous one was.  The COM ports are turned off on this machine (as is the USB interface).

Unfortunately the problem we were experiencing with the old machine, that unloading certain models was causing others to twitch and that dolphin IPC writes were being dropped, is still there.  So the problem doesn't seem to have anything to do with hardware settings...

After some playing, Rolf and Alex determined that for some reason the c1rfm model is coming up in a strange state when started during boot.  It runs faster, but the IPC errors are there.  If instead all models are stopped, the c1rfm model is started first, and then the rest of the models are started, the c1rfm model runs ok.  They don't have an explanation for this, and I'm not sure how we can work around it other than knowing the problem is there and do manual restarts after boot.  I'll try to think of something more robust.

A better "fix" to the problems is to clean up all of our IPC routing, a bunch of which we're currently doing very inefficient right now.  We're routing things through c1rfm that don't need to be, which is introducing delays.  It particular, things that can communicate directly over RFM or dolphin should just do so.  We should also figure out if we can put the c1oaf and c1pem models on the same machine, so that they can communicate directly over shared memory (SHMEM).  That should cut down on overhead quite a bit.  I'll start to look at a plan to do that.

I fixed up the seismic.stp file for the StripTool display:

1. All BLRMS channels now have a y-axis range of 3 decades. So they all are displaying the same relative changes.
2. So the 0.01-0.1 Hz band which is all over the place is real, sort of. Masha says that it is due to the seismometer signal being dominated by noise below 0.1 Hz. She is going to fix this somehow.
3. I changed the samping time from 1 sec. to 10 sec. to make the traces less fuzzy.
4. We (Masha / Liz) should harmonize the colors of this file with what's on the summary pages.

I'm ~30% of the way through implementing LSC whitening filter triggers.  I think that everything I have done should be compile-able, but please don't compile c1lsc tonight.  I haven't tested it, and some channel names have changed, so I need to fix the LSC screen when I'm not falling asleep.

Also, Rana pointed out that we may not want the whitening to trigger on immediately upon acquiring lock - if there are other modes ringing down in the cavity, or some weird transients, we don't want to amplify those signals.  We want to wait a second or so for them to die down, then turn on analog whitening.  Jamie - do you know how long the "unit delay" delays things in the RCG?  Do those do what I naively think they do?  I'll ask you in the morning.

A Matlab script to calculate Wiener filter coefficients and convert fir to iir is ready. Input is a file with zero mean witness and desired signals, output is a Foton zpk command to specify iir filter.

The plot shows comparison of offline fir , iir and online iir filtering. Spectrum below 4 Hz is still oscillating due to acoustic coupling, this is not a filtering effect. At 1 Hz actuator is badly compensated, more work should be done. Other then that online and offline filtering are the same.

Den and I measured the differential motion of the x and y arms using Guralp 1 at the end of the y arm, Guralp 2 at the beamsplitter, and the Streckeisen at the end of the x arm.

I calibrated the Streckeisen to the Guralp by calculating the relative gain of the seismometer signals at the microseism. The Guralp 1-y amplitude was 1.0237 times Guralp 2-y and Guralp 2-x was 38.54 times STS-x. The Guralp calibration (to go from counts to meters) I used was 0.61/1000/800/80/(2*pi*f) m/count.

The differential motion should keep decreasing at low frequencies because the ground will move together at such large wavelengths. It goes up because the seismometer noise begins to dominate at low frequencies (below about 0.5 Hz). Another possible error source could be that the seismometers are not perfectly aligned along the arm.

0) Did a bunch of alignment to get beams roughly centered on ETMY and ITMY and maximize power. Adjusted the aperture and focus on ETMY camera to get nice image. Camera needs to be screwed in tightly and cables given some real strain relief, Steve.

1) snapshots not working on many MEDM screens. Who's on top of this?

2) save/restore not working for PZT2 sliders

3) changed power and filter triggers on yarm to match xarm

4) yarm filters copied from xarm (need to handtune RGs)

5) DTT wasn't working on rossa. Used the Date/Time GUI to reset the system time to match fb and then it stopped giving 'Test Timed Out'. Jamie check rossa ntpd.

6) Removed the high 3.2 Hz RG filter. We don't have any sharp features like that in the spectrum.
   ---then added it back. The 3.2 Hz comes and goes depending on what Yoichi is doing over in the MC area. Leaving it in by default, but lowering the Q from 2 to 1.5.

7) Attached is the noise spectra, coherence, and loop gain model for this yarm condition. For the plant model, I assume a pendulum (f=1 Hz, Q = 9) and a cavity pole of 1600 Hz. Gain is scaled to set the UGF at 165 Hz (as guessed by looking at the servo gain peaking frequency). This cheezy model doesn't include any of the delays from DAC, AA, or AI. Eric and Sasha should have something more useful for us by Friday.

8) Change the DQ channels: need XARM and YARM IN1 at 16k. e.g. XARM_ERR, etc.

9) To get the DTT plots to make thumbnails in the elog, I print a .ps file and then use 'epstopdf' to make the PDF.

The unit delay delays for a single cycle, so I think that's not what you want.  I'm not sure that there's an existing part to add delays like that.

We also need to be a little clever about it, though, since we'll want it to flip off if we loose lock during the delay.

The lack of AA filter for MCL signal is RFM model strongly disturbed entering to OAF signal

This week I've been focusing mainly on two things: 1) Designing a port for the STACIS that will allow external actuation and/or local feedback and 2) Investigating the seismic differential motion along the interferometer arms.

The circuit for the port is just a signal summing junction (in case we want to do feedforward and feedback at the same time) with BNC inputs for the external signal and switches that allow you to turn the external signal or feedback signal on/off. I'll test this on a breadboard and post the schematic if it works. I looked at the noise of the geophone pre-amp and DAC, which would be the feedback and external signal sources, respectively. According to Rolf Bork, the DAC noise is 700 nV/rtHz, and I measured the pre-amp board's minimum noise level at 20*10^-6 V/rtHz (which seems quite high). Both these noises are higher than the op-amp noise for my circuit (I'm considering the op-amp LT1012), which according to the specs is 30 nV/rtHz. This confirms that my circuit will not be the limiting noise source. 

Along with Den, I calibrated the seismometers in the lab and measured the displacement differential arm motion (see eLog 7186: http://nodus.ligo.caltech.edu:8080/40m/7186). I'm trying to find a transfer function for the seismic stacks (and pendulum, but that's simpler) so I can calculate the differential motion in the chamber. After doing this offline, I'll make new channels in the PEM to look at the ground and chamber differential motion along the arms online.

I also am looking at the noise of the geophones with their shunt resistor (4k resistor across the coil) removed, to see if it improves the noise at low frequencies. My motivation for this was that the geophone specs show a better V/m/s sensitivity at low frequencies when the shunt resistor is removed, so the actual signal may become larger than the internal noise at these frequencies.

ntp is now installed on all the workstations.  I also added it to the /users/controls/workstation-setup.sh script

Over the past week I have been continuing to finalize the daily summary pages, attempting to keep the total run time under half an hour so that they can be run frequently.  I have had many hang ups with the spectrograms and am currently using second trends (with this method, the entire script takes 15 minutes to run).  I also have a backup method that takes 3 minutes of data for every 12 minutes, but could not implement any interpolation correctly.  This might be a future focus, or the summary pages could be configured to run in parallel and full data for the spectrograms can be used.  I configured Steve's tab to include one page of images and one page of plots and fixed the scripts so that it corrects for daylight savings time (at the beginning of the running, the program prints 'DST' or 'Not DST').

Right now, I am focusing on making coherence plots in a spectrogram style (similar to the matlab 'coh_carpet' function) and a spectrogram depicting Gaussianity (similar to the plots made by the RayleighMonitor).  I have also been working on my  final paper and presentation.

Transmission of signals between RFM and OAF is bad again. Now we do not see any errors in IPC_ERR monitors so models think that they get all data but the data is wrong

The drawing of the 4' x 2'  table cover can be seen at entry  #6190 The new proposed wall #7106  The yellow acrylic would be ~ 0.25" thick and it will be the inside. It is not shown on the drawing.

Question remaining: should get a larger table 4' x 3' as outlined by red lines and make new cover to fit this

The oplev beam path needs larger incident angle to get in and out of the chamber: REMOVE BOTTLENECK for easy traffic

Moving the existing table closer to ETMY chamber - as Jamie suggested-  would help but there is no room for this solution.

The larger table solve this issue and leave more room for initial pointing, arm transmitted and future experiments.

Other benefits: no tube to make between table and chamber. It is easier to make the the larger box air tight.

The new isolation box with feed through, cover, seals will cost $4-5K ea

This week I took more data for the calibration of YARM. The summary of measurements taken is:

1. Peak-to-peak on Michelson
2. Michelson open loop
3. Excite ITMY and measure on AS55_Q_ERR
4. Excite ITMY and measure on POY11_I_ERR
5. Excite ETMY and measure on POY11_I_ERR
6. YARM open loop

Then I worked on comparing these measurements to the Simulink model of the interferometer control loop. The measured open loop transfer function of the YARM matched well with the model above about 20 Hz, after the gain was scaled properly to fit the data. Next is to fit the length response function of the model and the measurements, and then use DTT to calibrate the arm cavity's power spectrum.

Finally ringdown at IMC conquered and oopsie that came out so clean!

The finesse of the cavity from the current ringdown measurement, F= 453, differs from the measurements made in the document dated 10/1/02 on dcc...not sure if things have changed since then.

While I thought that the bumps observed at the end of the ringdown might be because of the cavity trying to lock itself, Jan commented that they have always existed in these measurements and their source is not known yet.

As Rolf pointed out when he was here yesterday, all of our IOPs are filled with parts for ADCs and DACs that don't actually exist in the system.  This was causing needless module error messages and IOP GDS screens that were full of red indicators.  All the IOP models were identically stuffed with 9 ADC parts, 8 DAC parts, and 4 BO parts, even though none of the actual front end IO chassis had physical configurations even remotely like that.  This was probably not causing any particular malfunctions, but it's not right nonetheless.

I went through each IOP, c1x0{1-5}, and changed them to reflect the actual physical hardware in those systems.  I have committed these changes to the svn, but I haven't rebuilt the models yet.  I'll need to be able to restart all models to test the changes, so I'm going to wait until we have a quiet time, probably next week.