I edited c1psl.db to include the following: 


grecord(calc, "C1:PSL-PMC_LOCALC")
{
        field(INPB,"C1:PSL-PMC_LODET")
        field(SCAN,".1 second")
        field(PREC,"4")
        field(CALC,".955*LOGE(B)-17.11")
}

 As it turns out, I apparently can't tell X from Y when fitting a function in a rush.  The real calibration stuff which is now in c1psl.db is:

grecord(calc, "C1:PSL-PMC_LOCALC")
{
        field(INPB,"C1:PSL-PMC_LODET")
        field(SCAN,".1 second")
        field(PREC,"4")
        field(CALC,"1.004*LOGE(B)+17.76")
}

I restarted c1psl (again, had to go hit the physical reset button since it didn't come back after a telnet-reboot) to have it take in the changes.  The psl.db file that was in place before yesterday (before I touched it) is saved as psl.db.15Apr2009 just in case.

I edited the PMC EPICS screen to have the LO mon look at C1:PSL-PMC_LOCALC, which is the calibrated channel in dBm.  I also stuck a little label on the screen saying what units it's in, because everyone likes to know what units they're looking at.

[Mirko, Jenne]

Mirko edited c1pem to have some new BLRMS channels.

I added a master Enable switch to the c1oaf.

Both were compiled, and restarted.  fb rebooted.  All looks okay (hopefully)

I ran a simulation of a double cavity with a PRC length mismatched w.r.t. the modulation frequency. I summarized the results in the attached PDF. I think it would be important to have a cross check of the results.

In brief:

A mismatch between PRC length and modulation frequency do have an effect on error signals

Multiple zeros appear in REFL_3f/PRCL that can be removed by careful tuning of the demodulation phase (however, the shape of the signal makes difficult to understand which phase is good…)

No visible effect on REFL_1f/CARM

But a large PRCL signal appears in REFL_1f_I, which is used to control CARM. This is not good.

A mismatch of the order of 0.5 cm has a small effect.

 [ericq,Gabriele]

So, we want an relatively quick measurement of the PRC length error (with sign!) at the order of .5 centimeter or so. Rana suggested the "demodulation phase method," i.e. lock the simple Michelson, measure what demodulation phase brings the 1F signal entirely within the phase quadrature, then lock the PRMI and measure the demodulation phase again. This tells you something about the length of the PRC. 

Gabriele and I worked through a simulation using MIST to determine how to actually do this. We simulated the case of injecting a line at 1kHz in the laser frequency via the laser's PZT and looking at the transfer function of the 1kHz signal to the I and Q at the 1F AS demodulated signal when locked. (Michelson locked on the dark fringe, PRC locked on 11MHz sideband) With the I and Q in hand, we can measure some demodulation phase angle that would bring everything into I. 

When the PRC length is in the ideal location, the demodulation phases in the two cases are the just about the same. Sweeping the length of the PRC around the ideal length gives us a monotonic function in the difference in the demodulation phases:

So, with this simulation, we should be able to calibrate a measured difference in demod phase into the length error of the cavity! We will proceed and report...

 [Gabriele, EricQ]

Actually it is difficult to see any laser frequency line in the dark fringe signal, since the Schnupp asymmetry is small. It is much better to use a differential MICH excitation which gives a better signal at the dark port.

We repeated the simulation explained before. We can use both the AS55 or the AS11 signals, bout the first one has a limited linear range and the expected 4cm value is very close to saturation.

[ericq, Gabriele, Manasa]

 We wanted to perform the PRC length measurement today with an AS11 signal, but such a signal didn't exist. So, we have temporarily connected the AS110 PD signal (which is some Thorlabs PD, and not a resonant one) into the REFL11 demod board. 

We then proceeded with the goal of locking the PRC with REFL165. A few parameters that were changed along the way as we aligned and locked things:

• the XARM gain was increased from 0.4 to 0.5 to help it acquire lock
• the MICH gain was decreased from -10 to -5 since there was some gain peaking in its servo output
• the REFL165 demodulation phase was changed from 155 to 122, to place a PRCL excitation entirely within I (we did this while locked on the carrier)

Sadly, in the end, we couldn't lock the PRC on a sideband in a stable manner. The alignment would drift faster than we could optimize the alignment and gains for the PRC. I.e. we would lock the PRC on the carrier, align PRM (and maybe touch ITMX) to maximize POPDC, switch to sideband locking, try to lock, and things would start looking misaligned. Switching back to carrier locking, the beam spots on REFL (for example) would have moved.

Manasa noted the MC_TRANS_Y has been substantially drifting along with small drift in MC_TRANS_P as well. So we need to fix the source of the mode cleaner beam drifting if we want to make this measurement. 

 Its very doubtful that the MC yaw drift matters for the IFO. That's just a qualitative correlation; the numbers don't hang together.

 Then there must be something else slowly drifting. It was very clear that the good alignment of the IFO was every time lost after few minutes...

The new ETMX ruby guide rods are slightly thicker than the old aluminum ones; specifically 1.27mm vs 1.0mm.

Since we did not change the guide rod location in response to this fact, the vertical position of the suspension point changes, which in turn changes the dynamics of the suspension. Specifically, since the standoff is placed below the guide rod, the suspension point is lowered, which makes the pitch mode softer. I crunched a few numbers and have determined that this effect should not be a problem.

Given the wiki's value of the ETMX pitch resonance frequency of 0.829 Hz, I predict a the new pitch resonance frequency of 0.800 Hz.

(wiki link: https://wiki-40m.ligo.caltech.edu/Suspensions/Mechanical_Resonances)

A useful document about the dynamics of our suspension can be found at T000134

From this document, one will find that the effect of changing the suspension point height over the optic center of mass,`b`, on the pitch resonance frequency (while keeping all other dimensions equal) to be:

The top of the standoff is fixed by the guide rod, so let's say that b' is given by the position of the center of the Ruby standoff. This is then smaller than the previous b by the differences in the radii of the standoffs:

The nominal value of b is 0.985mm. Thus, the pitch resonance frequency is changed by factor of 0.965, i.e. 3.5% smaller. Then, taking the wiki value of 0.829 Hz results in 0.800Hz, a 30mHz decrease.

I turned on the two remaining loops in the ASC system to see if we can lock.   I put in some ones into the WFS_OUTPUT matrix

and locked the MC2_TRANS_PIT and MC2_TRANS_YAW loops.

The effect of doing so is visible in the error signals.  The black loops are with all ASC loops off, Blue traces are with the WFS1 and 2 loops locked and Red traces are with all loops locked.  I took the red traces to a lower frequency to see if the suppression of the error signals at low frequencies is disturbed by the switching on of the MC2_TRANS loops.  They seem to be working fine without adding any perturbation above the UGF.

I measured the  Transfer Function coefs (at 10Hz using the WFS Lockins)  with MC2_TRANS loops locked in this rudimentary fashion

The green and blue bits are the only relevant parts since we ignore the off diagonal parts.  And most of these off diagonal coefs are indeed quite small (<5% of the max).  I have marked the not-so-small ones in yellow.

I then calculated the output matrix elements in two different ways.

a) Using a null vector in the place of MC_DoF --> MC2_TRANS transfer coefs.  The output matrix we get is

b) Without using the null vector.  i.e. using the MC_DoF --> MC2_TRANS transfer coefs and inverting the full matrix.  The output matrix we get is

I plan to try out these two output matrices and measure the OL TFs of the MC2_TRANS and see if we can include these into ASC in a useful fashion.

[EricQ, Jenne]

The first half of our evening was spent working on CARM and DARM in PRFPMI, and then we moved on to the PRMI part.

I moved the DARM ALSdiff -> TransDiff transition to be after the CARM ALScomm -> SqrtInvTrans transition in the carm_cm_up script.  After I did that, I succeeded every time (at least  10?  We did it many times) to get both CARM and DARM off of the ALS signals. 

We tried for a little while looking at transitioning to REFL11 normalized by the sum of the transmissions, but we kept losing lock.  We also several times lost lock at arm powers of a few, when we thought we weren't touching the IFO for any transitions.  Looking at the lockloss time series did not show any obvious oscillations in any of the _IN1 or _OUT channels for the length degrees of freedom, so we don't know why we lost lock, but it doesn't seem to be loop oscillations caused by changing optical gain.  Also, one time, I tried engaging Rana's "Lead 350" filter in FM7 of the CARM filter bank when we were on sqrtInvTrans for CARM, and the arm powers were around a few, but that caused the transmission signals to start to oscillate, and after one or two seconds we lost lock.  We haven't tried the phase lead filter again, nor have we tried the Boost2 that is in FM8. 

We increased the REFL11 analog gain from 0dB to 12dB, and then reset the dark offsets, but still weren't able to move CARM to normalized REFL11. Also, I changed the POP22 demod phase from 159 degrees to 139 degrees. This seems to be where the signal is maximized in the I-phase, while the arms are held off resonance, and also partway up the resonance peak. 

We then decided that we should go back to the PRMI situation before trying to reduce the CARM offset further.  We can robustly and quickly lock the PRMI on REFL33 while the arms are held off resonance with ALS.  So, we have been trying to acquire on  REFL33 I&Q, and then look at switching to REFL 165 I&Q.  It seems pretty easy to get PRCL over to REFL165 I (while leaving MICH on REFL33 I).  For REFL33, both matrix elements are +1.  For PRCL on REFL165, the matrix element is -0.08.  We have not successfully gotten MICH over to REFL 165 ever this evening. 

We went back and set the REFL165 I&Q offsets so that the outputs after the demod phase were both fluctuating around 0.  I don't know if they were around +/-100 because our dark offsets were bad or what, but we thought this would help.  We were still able to get PRCL transitioned no problem, but even after remeasuring the MICH REFL33 vs. REFL165 relative gains, we still can't transition MICH.  It seems like it's failing when the REFL33Q matrix element finally gets zeroed out, so we're not really getting enough signal in REFL165Q, or something like that, and throughout the rest of the transition we were depending entirely on REFL33Q. 

So. Plan:

• Get PRMI on REFL165 while arms are held off resonance. 
  • May require PRCL-MICH FF decoupling, by combining error signals?
  • May require looking back at simulations to see what we expect the relative gains and signs to be.
• Look at CARM loop stability in simulation for REFLDC, REFL11, and normalized REFL11.  Is there a stable loop path from about 100pm down to 0pm on normalized REFL11?

Earlier in the morning I tried to align the green laser of the X-arm. It was an attempt to see if green transmission can be brought up to some level. Unfortunately as seen from Koji's post, this led the IR alignment to go off.

Thanks to Koji, Hiroki and Mayank who were able to remedy this and get the green beam aligned, I can now start working on the PDH controller and run some tests with the Moku:Go.

In the meantime, a model of the plant and controller was made in Python, using a mix of transfer functions of the components taking data from Gautam's thesis, as well as frequency response data collected earlier by Radhika of the PZT and the PDH Servo Box. The open loop transfer function was calculated using the model, then tweaked to fit the open loop transfer function of the actual system collected earlier using the Moku:Go. We now have a model on which new controllers can be tested.

Expanding on the single-layer model, I added the second, third, and fourth layers to the stack in COMSOL. Eigenfrequency analysis run times increased exponentially as the model multiplied in complexity. The following images document the some of the important eigenfrequencies:

First Eigenmode: y-translational, 3.34 Hz:

Second Eigenmode: x-translational, 3.39 Hz:

Third Eigenmode: z-rotational, 3.88 Hz:

Sixth Eigenmode: z-translational, 8.55 Hz:

As expected, the eigenfrequencies are generally lower, but still in the same range, as the single-layer model, because of greater mass but constant weight-per-spring distribution.

Next Steps:

1) Extend a single stack to the full stack system, which consists of three stacks like this. Perform similar eigenmode analysis.

2) Analyze the mirror suspension system and incorporate a similar pendulum on the top plate.

3) Make transfer function measurements between seismic and mirror motions.

Eigenfrequency analysis has been successfully completed in COMSOL on both a tutorial camshaft, as well as a homemade metal bar.

Upon increasing in complexity to the busbar, I once again began getting into run time errors and increased lag. It seems that this is due to undefined eigenvalues when solving the linear matrices. I tried many boundary values as well as initial conditions in case this was the issue, but it was not. There seems to be some sort of an internal inconsistency. This is no longer a matter of tweaking parameters.

Next steps:

1) Try using the same techniques on the actual mirror stacks to see if we get lucky.

2) In the likely case that this doesn't happen, continue the debugging process. If necessary, a good deal of time may need to be spent learning the COMSOL lower-level jargon.

Via reconfiguration of Viton parameters (previously posted), I managed to debug the COMSOL run time errors and null pointer exceptions. Listed are the resultant eigenfrequencies obtained through structural analysis testing. For all tests, the bottom of the Viton springs are constrained from motion, and all other parts are free to oscillate. Notice that color variations signify displacement from the equilibrium position. Also note that different initial conditions produce different eigenmodes:

No initial displacement:

0.01 m x-displacement:

0.01 m y-displacement:

 0.01 m z-displacement:

Clearly, the plate has its first harmonic between 210-215 Hz, which is much greater than seismic noises (which never exceed the 10-Hz range). This suggests a highly attenuating transfer function. Since the remaining three plates have been designed to resonate similarly, it is likely that the entire stack system will also function very well.

Next steps:

1) Extend the eigenfrequency analysis to obtain a transfer function for the single-plate system

2) Expand the CAD model to include all four stack layers, and perhaps a base

I'm thinking of making some modifications to the RF distribution box in 1X2, so as to have an extra 55 MHz pickoff. Koji already proposed some improvements to the layout in 2015. I've marked up his "Possible Improvement" page of the document in Attachment #1, with my proposed modifications. I believe it will be possible to get 15-16 dBm of signal into a 4 way RF splitter in the quad demod chassis. With the insertion loss of the splitter, we can have 9-10 dBm of LO reaching each demod board, which will then be boosted to +20 dBm by the Teledyne on board. The PE4140 mixer claims to require only -7 dBm of LO signal. So we have quite a bit of headroom here - as long as we limit the RF signal to 0dBm (=0.5 Vpp from the LMH6431 opamp at 55 MHz, we shouldn't be having a much larger signal anyways), we should be just fine with 15 dBm of LO power (which is what we will have after the division into the I and Q paths, and nominal insertion losses in the transmission path). These numbers may be slight overestimates given the possible degradation of the RF amps over the last 10 years, but shouldn't be a show-stopper.

Do the RF electronics experts agree with my assessment? If so, I will start working on these mods tomorrow. Technically, the splitter can be added outside the box, but it may be neater if we package it inside the box. 

looks good to me.

The thing I usually look for is how much the downstream system (mixers, etc) can perturb the main oscillator. i.e. we don't want mixer in one chain to reflect back and disturb the EOM chain. But since our demods have amplifiers on the LO side we're pretty immune to that.

I got a bit confused by your description.

The demod board claims that the nominal power at each LO port is 10dBm. So we want to give at least 16dBm to the (external?) 4way power splitter, but we only have 15dBm. As you said, the actual LO power reaching the FET mixier (PE4140) is the level of ~20dBm. But you said the requirement for the mixer is -7dBm. So are you proposing to reduce the LO level (slightly) than the LIGO recommendation because the minimum for PE4140 is -7dBm?
If that's the message, then I can say "yes". We supply 8~9dBm to the LO ports instead of 10dBm. I suppose the mixers don't care about this level of reduction.

Looking at my original post [40m ELOG 11817], the necessary modification is much larger than you have indicated in your post (as yours is the modification of my modification plan.)
If you do your modification you have to deal with the components rearrangement in the chassis. I think you can still accomplish it as you are going to remove an amplifier and gain the space from it.

The main RF line still has 5dBm Attn. How about to insert another 3dB power splitter there and create a spare 55MHz port for the future use?

Before doing any modification you should check how much the distributed powers are at the ports.
Also your modification will change the relative phase between 11MHz and 55MHz.
Can you characterize how much phase difference you have between them, maybe using the modulation of the main marconi? And you might want to adjust it to keep the previous value (or any new value) after the modification by adding a cable inside?

I removed the Frequency Generation box from the 1X2 rack. For the time being, the PSL shutter is closed, since none of the cavities can be locked without the RF modulation source anyways.

Prior to removal, I did the following:

1. Measured powers at each port on the front panel 
   • Gigatronix power meter was used, which has a maximum power rating of 20dBm, so for the EOM drive outputs which we operate closer to 25-27 dBm, I used a 20 dBm coupler to make the measurement.
   • Attachment #1 summarizes my findings - there doesn't seem to be anything majorly wrong, except that for the 11 MHz EOM drive channel, the "7" setting on the variable attenuator doesn't seem to work. 
   • We can probably get a replacement from MiniCircuits, but since we operate at 0dBm variable attenuation nominally, maybe we don't need to futz around with this.
2. Measured the relative phasing between the 11 MHz and 55 MHz signals using an oscilloscope.
   • I measured the relative phase for the EOM drive channels, and also the demod channels.
   • The scope can accept a maximum of 5V RMS signal with 50ohm input impedance. So once again, I couldn't make a direct measurement at the nominal setting for the EOM drive channel. Instead, I used the variable attenuator to set the signal amplitude to ~2V RMS. 
   • I will upload the time-domain plots later. But we now have a record of the relative phasing that we can try and reproduce after making modifications. FWIW, my measured phase difference of 139 degrees is reasonably consistent with Koji's inferred from the modulation spectrum.

One thing I noticed was that we're using very stiff coax cabling (RG405) inside this box? Do we need to stick with this option? Or can we use the more flexible RG316? I guess RG405 is lower loss, so it's better. I can't actually find any measurement of the shielding performance in my quick google searching but I think the claim on the call yesterday was that RG405 with its solder soaked braids offer superior shielding.

Let's use RG405 for better shielding. It is not too stiff. The bending  (just once) does not break the cable.

Are you going to full replacement of the 55MHz system? Or just remove the 7dBm and then implement the proposed modification for the 55MHz line?

I'm open to either approach. If the full replacement requires a lot of machining, maybe I will stick to just the 55 MHz line. But if only a couple of new holes are required, it might be advantageous to do the revamp while we have the box out? What do you think?

BTW, now that I look more closely at the RF chain, I have several questions:

1. The 1 dB compression power of the ZHL-2 amplifiers is ~29 dBm, and we are driving it at that level. Is this okay? I thought we always want to be several dBm away from the 1dBm compression point?
2. Why do we have an attenuator between the Marconi input and the first ZHL-2 amplifier? Can't we just set the Marconi to output 8 or 9 dBm?
3. The Wenzel frequency multiplier is rated to have 13dBm input and 20 dBm output. We operate it with 12 dBm input and 19 dBm output. Why throw away 1 dBm?

I guess it is feasible to have +17 dBm of 55 MHz signal to plug into the Quad Demod chassis - e.g. drive the 55 MHz input with 20 dBm, pick off 3dBm to the front panel for ASC. Then we can even have several "spare" 55 MHz outputs and still satisfy the 9 dBm input that the ZHL-2 in the 55 MHz chain wants (though again, isn't this dangerously close to the 1dB compression point?). The design doc claims to have done some Optickle modeling, so I guess there isn't really any issue? 

1. That's true. But we are already in that regime with the Var attn at 0dB, aren't we? We can reduce the input to the amp by 1-2dBm sacrificing the EOM out by that amount (we can compensate this for the demo out by removing the 1dB attn).

2. Not 100% sure but one possible explanation is that we wanted to keep the Marconi output large (or as large as possible) to keep the SNR between the signal and the noise of the driver in Marconi. The attenuator is less noisy compared to the driver noise.

3. My guess is that theoretically we were supposed to have 13dBm input and 20dBm output in design. However, the actual input was as such.  We can restore it to the 13dBm input.

[Paco, Radhika]

ALS control of CARM

Yesterday evening, Paco and I aimed to:

Once e-FPMI was locked (POX + POY --> CARM_A), we fed the ALS beatnote error signals to CARM_B and slowly mixed CARM_A and CARM_B. ALS control of CARM was successful.

The final values used in C1LSC_AUX_ERR_MTRX were (-0.3 ALSX + 0.3 ALSY) --> CARM_B. Note that these signs depend on the sign of each beatnote. The sign of ALSY could be determined by giving an offset, but without an Acromag we had to use trial and error for the sign of ALSX. We observed that using 0.5 magnitude for each signal resulted in too high of a CARM UGF, making the loop unstable. The magnitudes were reduced to 0.3 to give us a comparable UGF to POX/POY control of CARM.

The final ALS CARM OLTF can be found in Attachment 1. Some "wobblyness" was observed in the OLTF. Attachment 2 shows the suppressed in-loop CARM_B error and the out-of-loop CARM_A error. We couldn't identify why CARM_A error has a notch ~325 Hz; this is also present when closing the loop with CARM_A.

We tried to add an LSC CARM offset (would push the PSL frequency away) but could not see the transmission in the arms drop.

Next steps

Increase stability of ALS CARM, turning loop gains

Achieve a CARM offset maintaining lock

Then proceed to lock PRMI sidebands and reduce the CARM offset for PRFPMI

I've worked on packing the components for the following chassis
- 5 16bit AI chassis
- 4 18bit AI chassis
- 7 16bit AA chassis
- 8 HAM-A coil driver chassis
They are "almost" ready for shipment. Almost means some small parts are missing. We can ship the boxes to the company while we wait for these small parts.

• DB9 Female Ribbon Receptacle AFL09B-ND Qty100 (We have 10) -> Received 90 on Apr 1st
• DB9 Male Ribbon Receptacle CMM09-G Qty100 (We have 10) -> Received 88 on Apr 1st
• 4-40 Pan Flat Head Screw (round head, Phillips) 1/2" long Qty 50 -> Found 4-40 3/8" Qty50 @WB EE on Apr 1st (Digikey H782-ND)
• Keystone Chassis Handle 9106 36-9106-ND Qty 50 -> Received 110 on Apr 1st
• Keystone Chassis Ferrule 9121 NKL PL 36-9121-ND Qty 100 -> Received 55 on Apr 1st
• Chassis Screws 4-40 3/16" Qty 1100 -> Received 1100 on Apr 1st
• Chassis Ear Screws 6-32 1/2" 91099A220 Qty 150 -> Received 400 of 3/8" on Apr 1st
• Chassis Handle Screws 6-32 1/4" 91099A205 Qty 100 -> included in the above
• Powerboard mounting screw 4-40 Pan Flat Head Screw (round head, Phillips) 1/4" long Qty 125 -> Received 100 on Apr 1st

And some more additional items to fill the emptying stock.

• 18AWG wires (we have orange/blue/black 1000ft, I'm sending ~1000ft black/green/white)
• Already consumed 80% of 100ft 9pin ribbon cable (=only 20ft left in the stock)

All small components are packed in the boxes. They are ready to ship.

1) Turning the whitening filter before the ADC on/off didn't changed the relative height of 60 Hz peak compared with the noise floor. When the whitening filter was turned on, increase of the dark noise measured at C1:LSC-****_(I|Q)_IN1 was roughly consistent by eye with the whitening filter transfer function (gain of 1 at DC, ~15 Hz zero x2, ~150 Hz pole x2), which suggests the 60 Hz pickup is before the whitening filter.

2) Attached is the electronics diagram around BH44 and BH55.

I measured electronics noise of WFSs and QPD (of the WFS/QPD, whitening, ADC...) by closing PSL and measuring the error signal. It was needed to put the offset in C1:IOO-MC_TRANS_SUMFILT_OFFSET to 14000 cts (without offset the sum of quadrants would give zero, and 14000 cts is the value when the cavity is locked). For WFS that are RF, if there is intensity noise at low frequencies, it is not affecting the measurement.

In the attachment please find the power spectrum of the error signal when the PSL shutter is on and off.

this is just the CDS error signal, but is not the electronics noise. You have to go into the lab and measure the noise at several points. It can't be done from the control room. You must measure before and afte the whitening.

[Paco, Tomislav]

We measured the electronics noise of the demodulation board, whitening board, and ADC for WFSs, and OPLEV board and ADC for DC QPD in MC2 transmission. We were using SR785.

Regarding the demodulation board, we did 2 series of measurements. For the first series of measurements, we were blocking WFS (attachment 1) and measuring noise at the output of the demod board (attachment 2a). This measurement includes dark noise of the WFS, electronics noise of demod board, and phase noise from LO. For the second series of the measurements, we were unplugging input to the demod board (attachment 2b & 2c is how they looked like before unplugging) (the mistake we made here is not putting 50-ohm terminator) and again measuring at the output of the demod board. This measurement doesn't include the dark noise of the WFS. We were measuring it for all 8 segments (I1, I2, I3, I4, Q1, Q2, Q3, Q4). The dark noise contribution is negligible with respect to demod board noise. In attachments 3 & 4 please find plots that include detection and demodulation contributions for both WFSs.

For whitening board electronics noise measurement, we were terminating the inputs (attachment 5) and measuring the outputs (attachment 6). Electronics noise of the whitening board is in the attachments 7 & 8.

For ADC electronics noise we terminated ADC input and measured noise using diaggui (attachments 9 & 10). Please find these spectra for WFS1, WFS2, and MC TRANS in attachments 11, 12 & 13.

For MC2 TRANS we measured OPLEV board noise. We did two sets of measurements, as for demod board of WFSs (with and without QPD dark noise) (attachments 14, 15 & 16). In the case of OPLEV board noise without dark noise, we were terminating the OPLEV input. Please find the electronics noise of OPLEV's segment 1 (including dark noise which is again much smaller with respect to the OPLEV's electronics noise) in attachment 17.

For the transfer functions, demod board has flat tf, whitening board tf please find in attachment 18, ADC tf is flat and it is (2**16 - 1)/20 [cts/V], and dewhitening tf please find in attachment 19. Also please find the ASD of the spectral analyzer noise (attachment_20).

Measurements for WFS1 demod and whitening were done on 5th of July between 15h and 18h local time. Measurements for WFS2 demod and whitening were done on 6th of July between 15h and 17h local time. All the rest were done on July 7th between 14h and 19h. In attachment 21 also find the comparison between electronics noise for WFSs and cds error signal (taken on the 28th of June between 17h and 18h). Sorry for bad quality of some pictures.

as I said to you yesterday, I don't think image 2a shows the output of the demod board. The output of the demod board is actually the output connector ON the demod board. What you are showing in 2a, is the signal that goes from the whitening board to the ADC I believe. I may be msitaken, so please check with Tega for the signal chain.

 With some assistance from Kiwamu and Koji, I've drawn up the electronics design for the Beat Box for the vertex green locking. The Omingraffle schematic is posted on the Green Locking Wiki page. It's also attached below. Some final touches are necessary before we can Altium this up.

 Attachment 1: Schematic of beatbox

Attachment 2: Front and back panel designs.

- AC coupling for the comparator circuit of the green locking

In order to relieve the power consumption of the RF buffer, ac coupling circuits have been added.

The ac coupling before the buffer amp helps to relieve the power consumption in the chip.
But because of the distortion of the signal (and the limitation of the bandwidth), the output still has some DC (~0.6V).
Therefore, the output is also AC coupled.

Note that the BW pin of BUF634P should be directly connected to -15V in order to keep the bandwidth of the buffer.

The drawings are also uploaded on the green electronics wiki

Nobody documented this, but here is the part number with mechanical drawings of the elliptical reflector installed at EY: Optiforms E180. Heater is from Induceramics, but I can't find the exact part which matches the dimensions of the heater we have (diameter = 3.8mm, length = 30mm), perhaps it's a custom part?

The geometry dictates that if we want the heater to be at one focus and the ETM to be at the other, the separation has to be 7.1 inches. It certainly wasn't arranged this way before. It seems unrealistic to do this without clipping the main beam, I propose we leave sufficient clearane between the main beam and the reflector, and accept the reduced heating efficiency. 

Thanks to Steve for digging this up from his secret stash.

 Elog was down, I restarted it.

Elog went nonreponsive. SSH'ed into nodus to run restart script. Elog came back ~15 minutes later.

Koji and Evan have both brought up a good point that we may not be backing up the svn and ELOG properly.

I have modified the rsync.backup script that nodus' cron runs every night that backs up /cvs/cds to what I presume are the tape backups at ldas-cit.ligo.caltech.edu.

Specifically, I added two rsync commands that grab the svn and elog directories from /export/home and copy them to their old locations in /cvs/cds/caltech. This way, the old locations are updated, and the tape backups stay current.

We want the elog process to run in verbose mode so that we can see what's going. The idea is to track the events that trigger the elog crashes.

Following an entry on the Elog Help Forum, I added this line to the elog starting script start-elog-nodus:

./elogd -p 8080 -c /cvs/cds/caltech/elog/elog-2.7.5/elogd.cfg -D -v > elogd.log 2>&1

which replaces the old one without the part with the -v argument.

The -v argument should make the verbose output to be written into a file called elogd.log in the same directory as the elog's on Nodus.

I haven't restarted the elog yet because someone might be using it. I'm planning to do it later on today.

So be aware that:

We'll be restarting the elog today at 6.00pm PT. During this time the elog might not be accessible for a few minutes.

 I tried applying the changes but they didn't work. It seems that nodus doesn't like the command syntax.

I have to go through the problem...

The elog is up again.

 I restarted it using start-elog-nodus and this worked out fine - even though I did it from Pete's on my phone ;-)

I'm going to take the elog down for one minute and restart it under gdb (using a copy of gdb stolen from fb40m since I couldn't figure out how to install an old enough version on nodus from source).  The terminal with information is running on Rosalba under the "Phase Noise" panel, so please don't close it.  Ideally, the next time the elog crashes, I'll have some output indicating why or at least the line in the code.  I can then look at the raw source code or send the line back to the developer and see if he has any ideas.

WTF?

The elog just crashed and I rebooted it

elogkeywd keyword1 keyword2 keyword3

I had to restart the elog on Nodus because it was no longer responding.

When I went to use the elog this morning, it wasn't responding.  I killed the process on nodus, and then restarted, per the 40m wiki instructions.

While I was writing up an elog entry, the elog died again, and I restarted it.  Not sure what caused it to die since no one was uploading to it at the time.

The elog crashed while I was creating an entry to the Cryo log. I restarted it with the start-elog.csh script.