40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 198 of 341  Not logged in ELOG logo
ID Date Author Type Category Subject
  7203   Thu Aug 16 13:04:36 2012 LizSummaryComputer Scripts / ProgramsDaily Summary Details

I just wrote a short description of how to run the daily summary pages and the configuration process for making changes to the site.  It can be found in /users/public_html/40m-summary and is named README.txt.  If I need to clarify anything, please let me know!  The configuration process should be relatively straightforward, so it will be easy to add plots or change them when there are changes at the 40 meter.

  7202   Thu Aug 16 05:08:38 2012 YoichiUpdateIOOMC Servo Transfer Function Measurements

Quote:

 Also the MC board includes many generic filter stages to customize the frequency response. I will open the MC board box to examine what is actually implemented on the board. 

 I took out the MC board. Unfortunately, most of the components are surface mounted. So the values of the capacitors are not legible.

I will try my best to guess what is implemented on the board.

Attachment 1: MCBoard1.JPG
MCBoard1.JPG
Attachment 2: MCBoard2.JPG
MCBoard2.JPG
  7201   Thu Aug 16 01:52:52 2012 YoichiUpdateIOOMC Servo Transfer Function Measurements

Quote:

Last night, I took a bunch of TFs with this method. Now I'm analyzing the data to recover the overall gain G. I will post the results later.

 I calculated the MC open loop transfer function with the combination method. For that, I made a circuit model of the MC board (from the input to the output). The transfer function of this circuit is calculated by SPICE (attachment1). Then it is multiplied by the measured transfer function from the output of the MC board to the input of the MC board (attachment 2) to get the overall transfer function.

The result is shown in the attachment 3. The blue curve is the OPLTF measured with the traditional method. The red curve is the combination method described above. There are some discrepancies between the two curves. The ratio of the two curves (Traditional)/(Combination) is plotted in attachment 4. It seems there is a pole(s) missing from my model of the MC board at around 1MHz. This may come from the omitted op-amps in the MC board model (there are so many op-amps which have flat responses below 1MHz and I omitted most of those). Also the MC board includes many generic filter stages to customize the frequency response. I will open the MC board box to examine what is actually implemented on the board. 

At low frequencies, the two curves are similar but the slope is still different.

I also had to add 83dB of gain to the combined TF to match with the traditional one. I will check where does it come from.

The MC board model (Altium project) is attached as attachment 6. The schematic is attachment 5.

Attachment 1: MC_Board_TF.png
MC_Board_TF.png
Attachment 2: OPTG.png
OPTG.png
Attachment 3: OPLG.png
OPLG.png
Attachment 4: Difference.png
Difference.png
Attachment 5: MC_Board.pdf
MC_Board.pdf
Attachment 6: MC_Board.zip
  7200   Wed Aug 15 20:53:48 2012 ManasaUpdateIOORingdown measurements

Quote:

Quote:

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.

What I meant to say was that in all ringdown measurements that we observed today, the bumps were consistently part the ringdown, and that I have no explanation for the bumps. It should also be mentioned that fitting the bumpy part of the ringdown instead (we used the clean first 10us), the ringdown time is about twice as high. In either case, the ringdown time is significantly smaller than we have seen in documents about previous measurements.

We (basically I) also made one error when producing the plots. The yaxis label of the semi-logarithmic plot should be log(...), not log10(...).

 I thought about  why we do not find any bumps beyond the exponential fall. Could it be because we neglected fluctuations of voltage in the negative direction and plotted the absolute values?

  7199   Wed Aug 15 20:15:51 2012 JanUpdateIOORingdown measurements

Quote:

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.

What I meant to say was that in all ringdown measurements that we observed today, the bumps were consistently part the ringdown, and that I have no explanation for the bumps. It should also be mentioned that fitting the bumpy part of the ringdown instead (we used the clean first 10us), the ringdown time is about twice as high. In either case, the ringdown time is significantly smaller than we have seen in documents about previous measurements.

We (basically I) also made one error when producing the plots. The yaxis label of the semi-logarithmic plot should be log(...), not log10(...).

  7198   Wed Aug 15 18:56:46 2012 YoichiUpdateIOOMC Servo Transfer Function Measurements

 I started working on the characterization of the MC servo.

The current MC servo topology is shown in the figure attached along with a simplified schematic diagram of the MC board. 

A usual way to measure the open loop gain of this servo is to inject a signal from, say, EXCA of the MC board and measure the transfer function from TP2A to TP1A. It works OK at frequencies around the UGF. The second attachment is the OPLTF measured in this way with the Agilent 4395A. The UGF is about 100kHz with the phase margin of 40 to 50 deg. 

Now we have two issues here. First, I expected the UGF to be more than 100kHz, like 300kHz or so. The phase babble is peaked around 100kHz. According to our old measurement (http://nodus.ligo.caltech.edu:8080/40m/1431) the phase babble peak was at a much higher frequency when the FSS was using the reference cavity. One reason could be that the MC is located much farther from the laser than the reference cavity, so that there is some phase lag caused by the time delay. I will make a model of the MC servo system later to check this theory.

The second issue is that, as you can see in the plot, the OPLTF measurement becomes noisy at lower frequencies. With 4395A, which has the minimum IFBW of 2Hz, OPLTF measurement below 10kHz was impossible with the traditional method. We could use SR785 with a long averaging time to improve the SNR, but it requires a patience which I don't have.

The measurement becomes difficult at low frequencies because the loop gain is too high. When the open loop gain (G) is high, the injected signal (x) from EXCA is immediately suppressed by a factor of 1/(1+G) at TP2A. This makes the injected signal hidden in other noises at TP2A.

How do we solve this problem ? Let's consider a simple servo model shown in the third attachment. A traditional OPLTF measurement is done by injecting a signal from EXC port and measuring the TF from TP2 to TP1. The problem was that at TP2, the signal is attenuated by 1/(1+G1*G2), which is too much when G (=G1*G2) is large. However, at TP3, the attenuated signal is amplified by G1. So the injected signal x becomes x*G1/(1+G) at TP3. If G1's contribution to the overall gain G is large enough,  the signal at TP3 is not so small. Then we can easily measure G2 using TP3 and TP1. In a typical situation, G1 is the transfer function of the electric circuits, which we can know either from standalone measurements or from model calculations, and G2 is an interferometer response, which we want to measure. So, by combining the knowledge of G1 and the measurement of G2, we can obtain the overall loop gain G even at lower frequencies.

 The final attachment shows an example of the measurement of G2. In our case, this is the transfer function from MC_Out_Mon to Q-Mon (see the first attachment) . G1 is the transfer function of the MC board. Since G1 is large at low frequencies, we can measure G2 down to 100Hz with a reasonable integration time (10000 cycles per point).

Last night, I took a bunch of TFs with this method. Now I'm analyzing the data to recover the overall gain G. I will post the results later.

Attachment 1: MC-Diagram.png
MC-Diagram.png
Attachment 2: OPLG-10kHz-1MHz.png
OPLG-10kHz-1MHz.png
Attachment 3: SimpleServoDiagram.png
SimpleServoDiagram.png
Attachment 4: OPTG-100Hz-1kHz.png
OPTG-100Hz-1kHz.png
  7197   Wed Aug 15 17:23:22 2012 jamieUpdateCDSfront end IOP models changed to reflect actual physical hardware

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.

  7196   Wed Aug 15 17:17:58 2012 Manasa, JanUpdateIOORingdown measurements

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.

Ringdown_815.jpg

  7195   Wed Aug 15 16:29:59 2012 Eric SummaryGeneralSURF Update

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.

  7194   Wed Aug 15 16:01:47 2012 steveUpdateGenerallarger optical tables at the ends ?

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

 

 

Attachment 1: bottleneck.jpg
bottleneck.jpg
  7193   Wed Aug 15 13:24:12 2012 DenUpdateCDSRFM -> OAF

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

oaf.png

  7192   Wed Aug 15 13:23:34 2012 LizSummaryComputer Scripts / ProgramsLast Weekly Update

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.

  7191   Wed Aug 15 11:44:35 2012 jamieSummaryLSCntp installed on all workstations

Quote:

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.

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

  7190   Wed Aug 15 11:40:15 2012 YaakovSummarySTACISWeekly Summary

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.

  7189   Wed Aug 15 10:40:16 2012 DenUpdateCDSaa filters

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

aa.png

  7188   Wed Aug 15 09:09:45 2012 jamieUpdateLSCLSC whitening triggers

Quote:

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.

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.

  7187   Wed Aug 15 04:03:55 2012 ranaSummaryLSCY-Arm Locking

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.

Attachment 1: yArmNoise_120815.png
yArmNoise_120815.png
Attachment 2: yarm.pdf
yarm.pdf
  7186   Wed Aug 15 01:14:19 2012 YaakovUpdatePEMDifferential Motion of X and Y Arm

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.

diff_motion_x_arm.pngdiff_motion_y_arm.png

Attachment 1: diff_motion_x_arm.png
diff_motion_x_arm.png
Attachment 2: diff_motion_y_arm.png
diff_motion_y_arm.png
  7185   Wed Aug 15 00:52:17 2012 DenUpdateWienerFilteringfilter calculation

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.

wiener.png

  7184   Tue Aug 14 22:16:46 2012 JenneUpdateLSCLSC whitening triggers

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.

  7183   Tue Aug 14 21:01:51 2012 ranaUpdatePEMBLRMS

Screenshot-Untitled_Window.png

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.
  7182   Tue Aug 14 17:47:44 2012 JamieUpdateCDSc1sus machine replaced

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.

 

  7181   Tue Aug 14 16:33:51 2012 SashaUpdateComputer Scripts / ProgramsSimPlant indicator added

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).

  7180   Tue Aug 14 16:19:12 2012 JenneUpdateGreen LockingXend doubling crystal heater unplugged, replugged

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.

  7179   Tue Aug 14 15:58:44 2012 JenneUpdateGeneralTranslation to English: larger optical tables at the ends

Quote:

Quote:

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.

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.

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.

 

  7178   Tue Aug 14 14:26:40 2012 SteveUpdateCamerascameras touched up

 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.

 

Attachment 1: cameras.png
cameras.png
  7177   Tue Aug 14 13:21:34 2012 JenneUpdateCDSIPC senders no nothing about rates of IPC receivers, we need to filter signals appropriately

Quote:

Quote:

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.

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

 *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.

  7176   Tue Aug 14 11:49:15 2012 DenUpdateCDSDebugging of c1sus machine and c1rfm models

Quote:

 

  We might just need to reduce the load on c1rfm, maybe by introducing a c1rfm2?

 

 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.

  7175   Tue Aug 14 11:46:22 2012 JamieUpdateCDSIPC senders know nothing about rates of IPC receivers, we need to filter signals appropriately

Quote:

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.

ai.png

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
  7174   Tue Aug 14 11:39:13 2012 Jamie, Rolf, AlexUpdateCDSDebugging of c1sus machine and c1rfm 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.

  7173   Tue Aug 14 11:33:14 2012 Jamie Alex DenUpdateCDSAI and AA filters

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.

ai.png

  7172   Tue Aug 14 08:43:42 2012 SteveUpdateIOOlaser off and on

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.

Attachment 1: 1day.png
1day.png
  7171   Tue Aug 14 04:53:45 2012 YoichiSummaryLSCX-Arm noise spectrum

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)"?

Attachment 1: xarm-spectrum.png
xarm-spectrum.png
  7170   Tue Aug 14 04:37:06 2012 YoichiSummaryLSCXARM Open Loop Gain

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).

Attachment 1: xarm-opltf.png
xarm-opltf.png
  7169   Tue Aug 14 04:32:49 2012 rana, yoichiUpdateLockingPOX signal sometimes looks very funny

 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.

ETMXF_1028975007.bmp

ETMXT_1028975105.bmpAS_1028975166.bmp

 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.

Attachment 1: ITMX_1028974969.bmp
  7168   Tue Aug 14 00:42:40 2012 JenneUpdateLockingPOX signal sometimes looks very funny

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.

Attachment 1: POX_13Aug2012_LSCdisabled_pox_is_normalish.png
POX_13Aug2012_LSCdisabled_pox_is_normalish.png
Attachment 2: POX_13Aug2012_LSCenabled_pox_is_squareish_funny.png
POX_13Aug2012_LSCenabled_pox_is_squareish_funny.png
  7167   Mon Aug 13 23:06:08 2012 JenneUpdateSUSSimplant left on

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.

 

 

  7166   Mon Aug 13 21:47:30 2012 YaakovUpdateSTACISTwo changes to STACIS noise budget

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:

noise_budget_8-13.bmpnoise_budget_8-13.fig

Attachment 1: noise_budget_8-13.bmp
  7165   Mon Aug 13 20:12:29 2012 jamieUpdateCDSc1sup model moved to c1lsc machine

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.

  7164   Mon Aug 13 19:29:10 2012 ManasaSummary Ringdown measurements

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.

  7163   Mon Aug 13 18:00:30 2012 jamieUpdateGenerallarger optical tables at the ends

Quote:

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.

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.

  7162   Mon Aug 13 17:31:19 2012 jamieUpdateCDSmysterious stuck test points on c1spx model

Quote:

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.

  7161   Mon Aug 13 16:58:07 2012 jamieUpdateCDSmysterious stuck test points on c1spx model

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.

  7160   Mon Aug 13 15:31:09 2012 steveUpdateGenerallarger optical tables at the ends

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.

Attachment 1: ETMYtable.jpg
ETMYtable.jpg
Attachment 2: ETMY4X3.jpg
ETMY4X3.jpg
  7159   Mon Aug 13 12:17:41 2012 ManasaConfigurationIOOPD from AP table removed

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.

  7158   Mon Aug 13 09:59:05 2012 KojiUpdateGeneralMysterious banging on emergency door

You mean 5000?

Quote:

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

 

  7157   Mon Aug 13 01:33:55 2012 DenUpdateGeneralMysterious banging on emergency door

Quote:

[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.

  7156   Mon Aug 13 00:33:06 2012 MashaUpdateGeneralMysterious banging on emergency door

[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.

  7155   Sun Aug 12 10:34:45 2012 KojiUpdateSAFETYexit door left unlocked

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

Quote:

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 ! 

 

  7154   Sun Aug 12 01:21:26 2012 steveUpdateSAFETYexit door left unlocked

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 !

 

ELOG V3.1.3-