40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 289 of 339  Not logged in ELOG logo
ID Date Author Type Category Subject
  2553   Fri Jan 29 12:06:58 2010 AlbertoUpdateABSLMeasurement running today at lunch time

I just started a measuremtn that will be running for the next hour or so. Please be careful with the interferometer.

  2552   Thu Jan 28 09:17:32 2010 AlbertoUpdateLSC166 Modulation turned off

I temporarily turned off the 166 modulation.

  2551   Thu Jan 28 09:14:51 2010 AlbertoConfigurationComputersc1iscey, c1iscex, c1lsc, c1asc rebooted

This morning the LSC scripts wheren't running properly. I had to reboot c1iscey, c1iscex, c1lsc, c1asc .

I burtrestored to Monday January 25 at 12:00. 

  2550   Wed Jan 27 11:02:30 2010 AlbertoUpdateABSLPRC Cavity Length
 I fitted the data from scanning the PRC by changing the beat frequency of the auxiliary laser beam with the PSL beam.
The data points that I've taken so far over the entire frequency range (0-300 MHz) are not continuous. For several reasons the PLL was unable to maintain lock for such a large range and I had to break it into smaller segments. The measurements to acquire them stretched over a too long period of time during which the status of the PRC changed.
 
Because of that, before I get a continuous set of data points (perhaps normalized by the circulating power inside of the cavity), I restricted the fit to a 55MHz range around 100MHz. I obtained the following numbers for the fit parameters:
Length PRC = 2.169 +/- 0.007 m
Schnupp Asymmetry: 0.471+/- 0.006 m
 
The fit is shown in the attached plot:
2010-01-21_PRCtransmissivityVsFit.png
When I fit over the entire set of data I get this:
 
2010-01-21_PRCtransmissivity_EntireFreqRange_VsFit.png
 
Length PRC = 2.224 +/- 0.005 m
Schnupp Asymmetry: 0.457+/- 0.005 m
 
The results are different. Evidently I have to improve the measurement. I'm working on it.
 
For posterity:
The function I used to fit the transmitted beat power vs. frequency is the following:
 
E_trans = - t_prm * r_itm * exp(1i*2*wb*l_prc/c) .* sin(wb*l_/c) ./ ( 1 + r_prm * r_itm * exp(1i*2*wb*l_prc/c) .* cos(wb*l_/c)
 
Where wb is the angular frequency of the beat, l_prc and l_ are the length of the PRC and the Schnupp asymmetry, respectively; r_itm, t_itm, r_prm, t_prm are reflectances and transmittances of PRM and ITM; c is the speed of light.
 
  2549   Tue Jan 26 20:18:32 2010 ranaConfigurationALARMop540m: alarms and BLRMS and StripTool restored

I turned the StripTool and ALARMS and BLRMS back on on op540m. Looks like it has been rebooted 5 days ago and no one turned these back on. Also, there was a bunch of junk strewn around its keyboard which I restrained myself from throwing in the trash.

The BLRMS trends should be active now.

  2548   Tue Jan 26 19:51:44 2010 Sanjit, ranaUpdateAdaptive FilteringOAF details

We turned on the OAF again to make sure it works. We got it to work well with the Ranger as well as the Guralp channels. The previous problem with the ACC is that Sanjit and Matt were using the "X" channels which are aligned the "Y" arm. Another casualty of our ridiculous and nonsensical coordinate system. Long live the Right Hand Rule!!

The changes that were made are:

  • use of RANGER channel (with ACC_MC1_X and/or ACC_MC2_X)
  • mu = 0.01, tau = 1.0e-6, ntaps = 2000, nDown = 16
  • nDelay = 5 and nDelay = 7 both work (may not be so sensitive on delay at low frequencies)
  • Main changes: filter bank on the PEM channels - ASS_TOP_PEM_## filters: 0.1:0, 1:, Notch24, AA32, gain 1
  • Added the AI800 filter for upsampling in MC1 (should not matter)

Other parameters which were kept at usual setting:

  • CORR: AI32, gain = 1
  • EMPH: 0.001:0, AA32, gain = 1
  • ERR_MCL: no filters, gain = 1
  • SUS_MC1: no filter, gain = 1
  • PEM Matrix: All zero except: (24,1), (15,2), (18,3)
  • ADAPT path filter: union of CORR and EMPH filters, gain 1
  • XYCOM switches # 16-19 (last four on the right) OFF 

Screenshots are attached.

Burt snapshot is kept as: /cvs/cds/caltech/scripts/OAF/snaps/ass_burt_100126_211330.snap

taken using the script: /cvs/cds/caltech/scripts/OAF/saveOAF

we should put this in ASS screen.


ERROR Detected in filter ASS_TOP_PEM_24 (RANGER): 1: was actually typed as a 1Hz high pass filter!

(Correcting this one seems to spoil the adaptation)

Possibly this makes sense, we may not want to block witness signals in the 0.1-20 Hz range.


  11:40 PM: Leaving the lab with the OAF running on 5 PEM channels (Ranger + Guralp 1&2  Y & Z). There's a terminal open on op440m which will disable the OAF in ~2.8 hours. Feel free to disable sooner if you need the MC/IFO.

Attachment 1: C1ASS_TOP.png
C1ASS_TOP.png
Attachment 2: C1SUS_SRM_XYCOM1.png
C1SUS_SRM_XYCOM1.png
Attachment 3: Untitled.png
Untitled.png
  2547   Tue Jan 26 03:28:56 2010 ranaUpdateABSL166 MHz sideband turned off

 

 You can turn the 166 off if you want. MZ is unhappy after its turned off, but that's just the thermal transient from removing the RF heat. After a several minutes, the heat goes away and the MZ can be relocked.

One of these days we should evaluate the beam distortion we get in EOMs because of the RF heat induced dn/dT. Beam steering, beam size, etc.

  2546   Mon Jan 25 16:46:33 2010 AlbertoUpdateABSL166 MHz sideband turned off

Quote:

I turned off the modulation at 166MHZ becasue I don't need it if I'm only locking the PRC.

It was introducing extra amplitude modulations of the beam which interfered with the AbsL's PLL photodiode.

I'm going to turn it back on later on.

 I turned back on the 166MHz modulation just a bit. I set the slider at 4.156.

When it was totally off the MZ seemd quite unhappy.

  2545   Mon Jan 25 16:30:37 2010 AlbertoUpdateABSL166 MHz sideband turned off

I turned off the modulation at 166MHZ becasue I don't need it if I'm only locking the PRC.

It was introducing extra amplitude modulations of the beam which interfered with the AbsL's PLL photodiode.

I'm going to turn it back on later on.

  2544   Mon Jan 25 11:42:24 2010 josephbUpdateComputersMegatron and BO board

I was talking with Vladimir on Friday discussing the Binary Output board, we looked at the manual for it (Contec DO-32L-PE) and we realized its an opto-coupler isolated open-collector output.  He mentioned they had the right kind of 50 channel breakout board for testing in Riccardo's lab.

This morning I borrowed the 50 channel breakout board from Riccardo's lab, and along with some resistor loads, test the BO board.  It seems to be working, and I can control the output channel on/off state.

  2543   Fri Jan 22 14:40:49 2010 AlbertoUpdateABSLOvernight measurement

Quote:

I'm leaving a measurement running overnight. It should be done in about one hour.

Tomorrow morning, If you need to use the interferometer, and you don't want to have the auxiliary beam going onto the dark port, you can turn down the flipping mirror and close the NPRO's mechanical shutter.

 This is what I measured last night:

2010-01-21_PRCtransmissivityVsModel.png

 This is not a fit. It's just a comparison of the model with the data.

  2542   Fri Jan 22 12:33:37 2010 josephb, alexUpdateComputersModified CDS_PARTS for Binary output

Turns out the CDSO32 part (representing the Contec BO-32L-PE binary output) rquires two inputs. One for the first 16 bits, and one for the second set of 16 bits.  So Alex added another input to the part in the library.  Its still a bit strange, as it seems the In1 represents the second set of 16 bits, and the In2 represents the first set of 16 bits.

I added two sliders on the CustomAdls/C1TST_ETMY.adl control screen (upper left), along with a bit readout display, which shows the bitwise and of the two slider channels. For the moment, I still can't see any output voltage on any of the DO pins, no matter what output I set.

 

  2541   Fri Jan 22 02:54:06 2010 AlbertoUpdateABSLOvernight measurement

I'm leaving a measurement running overnight. It should be done in about one hour.

Tomorrow morning, If you need to use the interferometer, and you don't want to have the auxiliary beam going onto the dark port, you can turn down the flipping mirror and close the NPRO's mechanical shutter.

  2540   Thu Jan 21 17:23:30 2010 josephb,alex,kojiHowToComputersRCG code fixes

In order to see the Contec DO-32L-PE Digital output PCIe card with the new controls, we had to add the CDO32 part to the CDS_PARTS.mdl file in control /cds/advLigo/src/epics/simLink/ directory on megatron, as well as create the actual model mdl file (based on cdsDio.mdl) in the control/cds/advLigo/src/epics/simLink/lib directory. 

The CDO32.pm file (in /home/controls/cds/advLigo/src/epics/util/lib) has existed for some time, it was just missing the associated pieces in simlink.  However, Alex also checked out a newer version Dio.pm in the process.  As we are not using this part at this time, it should be fine.

The code now compiles and sees the digital output card.

You need a special care on this block as it turned out that the code does not compiled if the "constant" block is connected to the input. You must use appropriate block such as bitwise operator, as shown below.

Attachment 1: CDO32.png
CDO32.png
  2539   Thu Jan 21 15:16:16 2010 josephb, kojiSummaryComputersMegatron used to lock Y arm

We succeeded in having a stable single arm (Y) lock using Megatron to replace c1iscey.

Now the lock with megatron is pretty easy. Really. It's very cool.

As we saw the oscillation of the YARM servo, we temporalily increased the gain of TRY filter by a factor of 2 (0.003->0.006). Also decreased the gain of YARM servo by the factor of  2 (1->0.5). This makes the servo gain reduced by a factor of 4 in total. This change seemed to come from the change of the ADC/DAC range.

We finally fixed the hi-gain pd transmission communications from Megatron to the c1lsc by tracking down the correct RFM memory location (which is unhelpfully labeled as a qpd channel in both losLinux and lsc40.m).  The memory location is 0x11a1e0, and is refered to as qpdData[3].

  2538   Thu Jan 21 11:08:30 2010 kiwamu, steveUpdateVACDry Pump replacement

 This morning I and Steve replaced  the dry fore pump of TP3, which is located under the y-arm.

After replacing it we confirmed vacuum normal condition. The fore line pressure of TP3 went down to 11 mTorr from 750 mTorr

  Attached picture is new pump after setup.

Attachment 1: DSCN0428.JPG
DSCN0428.JPG
  2536   Thu Jan 21 10:31:13 2010 KojiUpdateABSLSome preliminary results from measuring PRC's transmissivity for an amplitude modulated beam

Nice and interesting plot.

I suppose slight decrease of the Schnupp asymmetry (in your model) adjusts the discrepancy in the high freq region.
At the same time, it will make the resonance narrower. So you need to put some loss at the recombination (=on the BS)?

...of course these depends on the flatness of the calibration.

  2535   Thu Jan 21 10:09:27 2010 KojiSummaryIOOPhotos of the optical tables

I made a wiki page dedicated for the photos of the optical tables.
The current layouts were uploaded.

http://lhocds.ligo-wa.caltech.edu:8000/40m/Optical_Tables

  2534   Wed Jan 20 20:11:56 2010 AlbertoUpdateABSLSome preliminary results from measuring PRC's transmissivity for an amplitude modulated beam
Here I'm posting a plot showing a set of measurements that I made in the past few days to determine the absolute length of the PRC cavity.
As in my other AbsL measurements, I inject an auxiliary laser beam into the cavity and look at the transmission. In the PRC case, the beam is injected through the dark port and I look at a pick-off of the REFL beam. The aux laser is phase locked to the PSL beam and I control the differential frequency between the two. The PSL and the aux beam interfere and beat at their differential frequency.
 
The attached plot shows the transmitted power as a function of the beat frequency.
 
Fitting the data with the model would let me determine the cavity length. 
By now I can estimate the length of the PRC at about 2.257m, but it's still a rather approximate value.
I can't provide accurate error bars yet. I need to optimize the measurements to get a more precise value.
 
I will go more through the details of the measurement technique and of the fitting function as soon as I have more definitive results.
 
The data points shown here were taken at different times and not always in optimal alignment condition of the PRC. 
To get a good fit of the data I should have fewer frequency segments, taken in a shorter period of time, and in which the power circulating inside of the cavity (ie SPOB) fluctuates as little as possible.
 
For what regards the time needed for a measurements, I already significantly sped up the measurements (i.e. optimizing the scanning and acquisition GPIB scripts, and fixing a couple of problems with the PDH box used in the PLL), and finally now I can scan several tens of MHz in few minutes.
About the frequency segments, so far they have been determined by two factors
1) Tthe frequency generator in the PLL: the Marconi works as a continuous wave generator only in limited ranges. Switching from one to another brakes the wave in a way that causes the PLL to lose lock.
2) Getting below 18 MHz a series of other beats appear on the PLL photodiode and make the PLL lose lock.
 
For the first problem, I'm thinking of using two Marconis and to mix their signals. I would keep one at 300MHz and I would scan the other from 300MHz to 500MHz. In fat, in that frequency range the Marconi has not discontinuity.
 
To try to avoid the other beats at low frequency, I'm not entirely sure about what to do yet. 
 
To be continued...
Attachment 1: 2010-01-19_PRCtransmissivityVsModel.png
2010-01-19_PRCtransmissivityVsModel.png
  2533   Tue Jan 19 23:26:07 2010 kiwamuUpdateElectronicsRe:Re: triple resonant circuit for EOM

Quote:

5.  For the impedance matching, I will select a transformer so that 55MHz is matched. In contrast I will leave two lower resonances as they are.

This is because 11MHz and 29.5MHz usually tend to have higher impedance than 55MHz. In this case, even if the impedance is mismatched, the gain for these can be kept higher than 11.

I will post the detail for this mismatched case tomorrow.

 

Here the technique of the impedance matching for the triple resonant circuit are explained.

In our case, the transformer should be chosen so that the impedance of the resonance at 55MHz is matched.

We are going to use the transformer to step up the voltage applied onto the EOM.

To obtain the maximum step-up-gain, it is better to think about the behavior of the transformer.

When using the transformer there are two different cases practically. And each case requires different optimization technique. This is the key point.

By considering these two cases, we can finally select the most appropriate transformer and obtain the maximum gain.

 

 


( how to maximize the gain ?)

Let us consider about the transformer. The gain of the circuit by using the transformer is represented by

eq1.png         (1)

Where ZL is the impedance of the load (i.e. impedance of the circuit without the transformer ) and n is the turn ratio.

It is apparent that G is the function of two parameters, ZL and n.  This leads to two different solutions for maximizing the gain practically. 

 

matching_edit.png

 

  - case.1 : The turn ratio n is fixed.

In this case, the tunable parameter is the impedance ZL.  The gain as a function of ZL is shown in the left figure above.

In order to maximize the gain, Z must be as high as possible.  The gain G get close to 2n when the impedance ZL goes to infinity.

There also is another important thing; If the impedance ZL is bigger than the matched impedance (i.e. ZL = 50 * n^2 ), the gain can get higher than n.

 

  - case.2 : The impedance ZL is fixed.

In contrast to case1, once the impedance ZL is fixed, the tunable parameter is n. The gain as a function of n is shown in the right figure above.

In this case the impedance matched condition is the best solution, where ZL=50*n^2. ( indicated as red arrow in the figure )

The gain can not go higher than n somehow. This is clearly different from case1.
 

 

( Application to the triple resonant circuit )

Here we can define the goal as "all three resonances have gain of more than n, while n is set to be as high as possible"

According to consideration of case1, if each resonance has an impedance of greater than 50*n^2 (matched condition) it looks fine, but not enough in fact.

For example if we choose n=2, it corresponds to the matched impedance of 50*n^2 = 200 Ohm. Typically every three resonance has several kOhm which is clearly bigger than the matched impedance successfully.

However no matter how big impedance we try to make,  the gains can not be greater than G=2n=4 for all the three resonance. This is ridiculous.

What we have to do is to choose n so that it matches the impedance of the resonance which has the smallest impedance.

In our case, usually the resonance at 55MHz tends to have the smallest impedance in those three. According to this if we choose n correctly, the other two is mismatched.

However they can still have the gain of more than n, because their impedance is bigger than the matching impedance. This can be easily understand by recalling the case1.

 

(expected optimum gain of designed circuit)

 By using the equation (1), the expected gain of the triple resonant circuit including the losses is calculated. The parameters can be found in last entry.

designed_response.png

The turn ratio is set as n=11, which matches the impedance of the resonance at 55MHz. Therefore 55MHz has the gain of 11.

The gain at 11MHz is bigger than n=11, this corresponds to the case1. Thus the impedance at 11MHz can go close to gain of 22, if we can make the impedance much big.

 

  2532   Tue Jan 19 16:21:18 2010 AlbertoUpdateABSLWatchdogs not working and then fixed

This afternoon the watchdogs stopped working: they didn't trip when the suspension positions crossed the threshold values.

I rebooted c1susaux (aka c1dscl1epics0 in the 1Y5 rack), which is the computer that runs the watchdog processes.

The reboot fixed the problem.

  2531   Tue Jan 19 12:54:39 2010 AlbertoUpdateABSLMeasurement in progress

A measurement will be running for the next hour. Please be careful.

  2530   Tue Jan 19 10:30:29 2010 josephbUpdateComputersBoot fest to restart the computer and c1iscey not responding.

Quote:

Thi afternoon I found that the RFM network in trouble. The frontends sync counters had railed to 16384 counts and some of the computers were not responding. I went for a bootfest, but before I rebooted c1dcu epics. I did it twice. Eventually it worked and I could get the frontends back to green.

Although trying to burtrestore to snapshots taken at any time after last wednesday till today would make the RFM crash again. Weird.

Also, c1iscey seems in a coma and doesn't want to come back. Power cycling it didn't work. I don't know how to be more persuasive with it.

During the testing of Megatron as the controller for ETMY, c1iscey had been disconnected from the ethernet hub.  Apparently we forgot to reconnect it after the test.  This prevented it from mounting the nfs directory from linux1, and thus prevented it from coming up after being shutdown.  It has been reconnected, restarted, and is working properly now.

  2529   Tue Jan 19 03:27:47 2010 kiwamuUpdateElectronicsRe: triple resonant circuit for EOM

1. You are right, the gain for the single resonant circuit was about 9.3 in my measurement.

But the reason why the triple is better than the single resonant circuit comes from the transformer.

The impedance can be degraded by a loss of the transformer, because it got worse after applying the transformer in the past measurement.

Also I definitely confirmed that the circuit had the impedance of 7.2 kOhm at the resonance of 52.9MHz without the transformer.

So it shall give the gain of 12, but did not after applying the transformer.

 

2.  Yes, I think we need some variable components just in case.

 

5.  For the impedance matching, I will select a transformer so that 55MHz is matched. In contrast I will leave two lower resonances as they are.

This is because 11MHz and 29.5MHz usually tend to have higher impedance than 55MHz. In this case, even if the impedance is mismatched, the gain for these can be kept higher than 11.

I will post the detail for this mismatched case tomorrow.

 

Quote:

The design looks very good. I have some questions.

1. As far as I remember, you've got the gain of slightly worse than 10 for a 55MHz single resonant case. Why your expectation of the gain (G=11) for the highest resonance better than this?

Supposing the loss exists only on the EOM, the other part of the LC network for the triple work as an inductor at the resonant frequency. This is just equivalent as the single resonant case. So the expected gain at 55MHz should coincides with what we already have. Probably, the resistance of 4 Ohm that is used here had too rough precision???

2. How can you adjust the resonances precisely?

Do we need any variable components for Cs and Ls, that may have worse quality than the fixed one, generally speaking.
I myself has no experience that I had to tune the commercial EOM because of a drift or whatever. I hope if you can adjust the resonance with a fixed component it should be fine.

3. Changing Cp. What does it mean?

Do you put additional cap for Cp?

4. The resonances for the lower two look very narrow. Is that fine?

This will show up in a better shape if we look at the transfer function for the gain. Is this right?

If we have BW>100kHz, it is sufficient.

5. Impedance matching for the lower two resonances.

Yep. You know this problem already.

 

 

  2528   Tue Jan 19 03:20:28 2010 KojiUpdateElectronicsdesign complete --- triple resonant circuit for EOM ---

First I was confused, but now I think I understood.

My confusion:
If the k get bigger, L get smaller, C get bigger. This makes R(L) smaller and R(C) smaller. This sounds very nice. But why smaller k is preferable in the Kiwamu's result?

Explanation:
The resultant impedance of the network at a resonance is determined by Zres = L/(R C) or something like that. Here R = R(L)+R(C). (I hope this is right.)

Here larger Zres is preferable. So smaller R is nice.

But If the speed of reduction for R is slower than that of L/C (which is proportional to k^-2), increasing k does not help us to increase of Zres. And that's the case.

This means "if we can put the LC network in the box of EOM, we can do better job!" as we can reduce Cp.

Quote:

scaling.png


   Loss for Capacitor :  R(C) = 0.5 (C / 10pF)^{-0.3} Ohm

   Loss for Inductor :    R(L) = 0.1 ( L / 1uH) Ohm

  2527   Tue Jan 19 03:04:14 2010 KojiUpdateElectronicstriple resonant circuit for EOM

Self-follow:

I got the answer of Q3 from the follow-up entry.

For Q4, once you get the impedance of the LC network lower than n^2*50, the EOM gain will be quite low. This means that the resonance is anyway narrow.
I did some simple calculation and it shows that the width of the resonance will be 100kHz~500kHz. So it maybe OK.

Quote:

The design looks very good. I have some questions.

1. As far as I remember, you've got the gain of slightly worse than 10 for a 55MHz single resonant case. Why your expectation of the gain (G=11) for the highest resonance better than this?

Supposing the loss exists only on the EOM, the other part of the LC network for the triple work as an inductor at the resonant frequency. This is just equivalent as the single resonant case. So the expected gain at 55MHz should coincides with what we already have. Probably, the resistance of 4 Ohm that is used here had too rough precision???

2. How can you adjust the resonances precisely?

Do we need any variable components for Cs and Ls, that may have worse quality than the fixed one, generally speaking.
I myself has no experience that I had to tune the commercial EOM because of a drift or whatever. I hope if you can adjust the resonance with a fixed component it should be fine.

3. Changing Cp. What does it mean?

Do you put additional cap for Cp?

4. The resonances for the lower two look very narrow. Is that fine?

This will show up in a better shape if we look at the transfer function for the gain. Is this right?

If we have BW>100kHz, it is sufficient.

5. Impedance matching for the lower two resonances.

Yep. You know this problem already. 

 

  2526   Tue Jan 19 02:40:38 2010 KojiUpdateElectronicstriple resonant circuit for EOM

The design looks very good. I have some questions.

1. As far as I remember, you've got the gain of slightly worse than 10 for a 55MHz single resonant case. Why your expectation of the gain (G=11) for the highest resonance better than this?

Supposing the loss exists only on the EOM, the other part of the LC network for the triple work as an inductor at the resonant frequency. This is just equivalent as the single resonant case. So the expected gain at 55MHz should coincides with what we already have. Probably, the resistance of 4 Ohm that is used here had too rough precision???

2. How can you adjust the resonances precisely?

Do we need any variable components for Cs and Ls, that may have worse quality than the fixed one, generally speaking.
I myself has no experience that I had to tune the commercial EOM because of a drift or whatever. I hope if you can adjust the resonance with a fixed component it should be fine.

3. Changing Cp. What does it mean?

Do you put additional cap for Cp?

4. The resonances for the lower two look very narrow. Is that fine?

This will show up in a better shape if we look at the transfer function for the gain. Is this right?

If we have BW>100kHz, it is sufficient.

5. Impedance matching for the lower two resonances.

Yep. You know this problem already.

 

  2525   Tue Jan 19 02:39:57 2010 kiwamuUpdateElectronicsdesign complete --- triple resonant circuit for EOM ---

The design of the triple resonant circuit has been fixed.

I found the optimum configuration, whose gain is still 11 at 55MHz even if there are realistic losses.

As I mentioned in the last entry, there are infinite number of the similar solutions to create the same resonant frequencies.

However owing to the effect of the losses, the resultant gain varies if the similar solution changes

The aim of this study is to select the optimum solution which has a maximum gain ( = the highest impedance at the resonance ).

In order to handle the losses in the calculation, I modeled the loss for both inductors and the capacitors.

Then I put them into the circuit, and calculated the impedance while changing the solutions.

 


 

(method)

1). put the scaling parameter as k in order to create the similar solution.

2). scale the all electrical parameters (L1, L2,...) by using k, so that C1'=C1 x k, L1'=L1/k ,...

3). Insert the losses into all the electrical components

4). Draw the impedance curve in frequency domain.

5). See how the height of the impedance at the resonance change

6). Repeat many time this procedure with another k.

7). Find and select the optimum k

scaling.png

There is a trick in the calculation.

I put a capacitor named Cpp in parallel to the EOM in order to scale the capacitance of the EOM (see the schematic).

For example if we choose k=2, this means all the capacitor has to be 2-times larger.

For the EOM, we have to put Cpp with the same capacitance as Cp (EOM). As a result these two capacitors can be dealt together as 2 x Cp.

So that Cpp should be Cpp = (k-1) Cp, and Cpp vanishes when we choose k=1.

 

The important point is that the scaling parameter k must be greater than unity, that is k > 1.

This restriction directly comes from Cp, the capacitance of the EOM, because we can not go to less than Cp.

If you want to put k < 1, it means you have to reduce the capacitance of the EOM somehow (like cutting the EO crystal ??)

 

(loss model)

I've modeled the loss for both the inductors and the capacitors in order to calculate the realistic impedance.

The model is based on the past measurements I've performed and the data sheet.

   Loss for Capacitor :  R(C) = 0.5 (C / 10pF)^{-0.3} Ohm

   Loss for Inductor :    R(L) = 0.1 ( L / 1uH) Ohm

Of course this seems to be dirty and rough treatment.

But I think it's enough to express the tendency that the loss  increase / decrease monotonically as  L / C get increased.

These losses are inserted in series to every electrical components.

( Note that: this model depends on both the company and the product model. Here I assume use of Coilcraft inductors and mica capacitors scattered around 40m )

 

( results )

The optimum configuration is found when k=1, there is no scaling. This is the same configuration listed in last entry

Therefore we don't need to insert the parallel capacitor Cpp in order to achieve the optimum gain.

The figure below shows the some examples of the calculated impedance. You can see the peak height decrease by increasing the scale factor k.

realistic.png

The black dash line represents the EOM-loss limit, which only contains the loss of the EOM.

The impedance at the resonance of 55MHz is 6.2 kOhm, which decreased by 3% from the EOM-loss limit. This corresponds to gain of G = 11.

The other two peaks, 11MHz and 29.5MHz dramatically get decreased from EOM-loss limit.

I guess this is because the structure below 50MHz is mainly composed by L1, L2, C1, C2.

In fact these components have big inductance and small capacitance, so that it makes lossy.

 

( next step )

The next step is to choose the appropriate transformer and to solder the circuit.

  2524   Tue Jan 19 00:10:44 2010 ranaUpdateElectronicstriple resonant circuit for EOM

Very cool.         

  2523   Mon Jan 18 23:44:19 2010 kiwamuUpdateElectronicstriple resonant circuit for EOM

The first design of the triple resonant EOM circuit has been done.

If only EOM has a loss of 4 Ohm, the gain of the circuit is expected to be 11 at 55MHz

So far I've worked on investigation of the single resonant circuit and accumulated the knowledge about resonant circuits.

Then I started the next step, designing the triple resonant circuit.

Here I report the first design of the circuit and the expected gain.

 


( What I did )

At first in order to determine the parameters, such as inductors and capacitors, I have solved some equations with numerical ways (see the past entry).

In the calculation I put 6 boundary conditions as followers;

(first peak=11MHz, second peak=29.5MHz, third peak=55MHz, first valley=22MHz, second valley=33MHz, Cp=18pF)

The valley frequencies of 22MHz and 33MHz are chosen in order to eliminate the higher harmonics of 11MHz, and Cp of 18pF represents the capacitance of the EOM.

Basically the number of parameters to be determined is 6 ( L1, L2, ...,), therefore it is completely solved under 6 boundary conditions. And in this case, only one solution exists.

The point is calculation does not include losses because the loss does not change the resonant frequency.

 

whole_circuit.png

( results )

As a result I obtained the 6 parameters for each components shown in the table below.

Cp [pF] 18.1
C1 [pF]  45.5
C2 [pF] 10.0
Lp [uH] 2.33
L1 [uH] 1.15
L2 [uH] 2.33

Then I inserted the loss into the EOM to see how the impedance looks like. The loss is 4 Ohm and inserted in series to the EOM. This number is based on the past measurement .

Let us recall that the gain of the impedance-matched circuit with a transformer is proportional to square-root of the peak impedance.

It is represented by G = sqrt(Zres/50) where Zres is the impedance at the resonance.

 As you can see in the figure, Zres = 6.4 kOhm at 55MHz, therefore the gain will be G=11 at 55MHz.

Essentially this gain is the same as that of the single resonant circuit that I've been worked with, because its performance was also limited mainly by the EOM loss.

 An interesting thing is that all three peaks are exactly on the EOM limited line (black dash line), which is represented by Zres = L/CR = 1/ (2pi f Cp)^2 R. Where R = 4 Ohm.

 designed_circuit.png

( next plan )

There are other solutions to create the same peaks and valleys because of the similar solution.

 It is easy to understand if you put Cp' = Cp x N, the solutions must be scaled like L1'=L1/N, C1'=C1 x N, ...,  Finally such scaling gives the same resonant frequencies.

So the next plan is to study the effect of losses in each components while changing the similar solution.

After the study of the loss I will select an optimum similar solution.

  2522   Mon Jan 18 20:58:40 2010 AlbertoUpdateABSLMeasurement in progress

Quote:

I started a long measurement of the PRC's transmissivity. I'm leaving the lab and I'm going to be back at about 8 tonight. Please do not disturb the interferometer. it is important that the MC and the PRC stay locked all the time.

 That measurement is finished. I'm now going to start another one that will take another hour or so. I'm leaving it running for the night. If you want to work on the IFO, it should be definitely done by 11pm.

  2521   Mon Jan 18 18:34:01 2010 AlbertoUpdateABSLMeasurement in progress

I started a long measurement of the PRC's transmissivity. I'm leaving the lab and I'm going to be back at about 8 tonight. Please do not disturb the interferometer. it is important that the MC and the PRC stay locked all the time.

  2520   Mon Jan 18 09:44:36 2010 Alberto, BobOmnistructureEnvironmentNo rain water infiltrations so far

It has rained continuously for the last 24 hours. Bob walked through the lab looking for possible water infiltrations. The floor looked dry: no puddles or leaks anywhere so far.

  2519   Sun Jan 17 19:18:55 2010 AlbertoUpdateComputersBoot fest to restart the computer and c1iscey not responding.

Thi afternoon I found that the RFM network in trouble. The frontends sync counters had railed to 16384 counts and some of the computers were not responding. I went for a bootfest, but before I rebooted c1dcu epics. I did it twice. Eventually it worked and I could get the frontends back to green.

Although trying to burtrestore to snapshots taken at any time after last wednesday till today would make the RFM crash again. Weird.

Also, c1iscey seems in a coma and doesn't want to come back. Power cycling it didn't work. I don't know how to be more persuasive with it.

  2518   Sun Jan 17 05:22:42 2010 ranaConfigurationComputersELOG script change

With Dave Barker's help, I changed the elog startup script. Instead of running as a Daemon with the -D option,

it now runs in the background with the unix "&". I think that the stdout and stderr are now redirected to a log file called elog.log.

We can 'tail -f' this file to see what its up to and debug any future crashing.

  2517   Fri Jan 15 18:53:05 2010 josephb,peter,kojiUpdateComputersAttempted locking with Megatron replacing ETMY front end

This afternoon we attempted to lock the interferometer using Megatron insteady of the usual ETMY front end.

We attempted it once, found the alignment seemed particularly bad, then realized we had forgotten to add the QPDs.  In the process of adding the QPDs to the tst.mdl file, we realized I (Joe) should have been looking at the iscNetDsc.h file, not the iscNetDs40m.h file for the RFM memory structure.  The only major difference was the memory location of where the qpd information gets passed.

We added QPDs to the tst.mdl file, writing to the RFM network with the QPD pitch, yaw and sum values.

We also added normalization to the oplev, by dividing the OL pitch and yaw values by the OL sum value in the tst.mdl file.

The lscPos, ascPit, ascYaw were working properly, although we did have to poke at the ascPit and ascYaw values once before they started reading properly at Megatron (they started at -1e20).  We think the RFM card may have started in an odd state, and without something causing the ascPit and ascYaw values to change, it never updated.

At the end of the day, the interferometer was locked for a few seconds.  There is are still some issues to be worked on, but its progress.

Koji returned everything back to normal operations after the test.

  2516   Fri Jan 15 12:04:26 2010 Sanjit, mevansUpdateAdaptive FilteringCanceling noise again!

 

OAF is successfully canceling noise again, thanks to Matt!

Here is a plot showing more than a factor of 10 noise reduction around 3Hz (similar to what we saw in the simulations)

The changes that has made it work are:

  • use of RANGER channel (with ACC_MC1_X and/or ACC_MC2_X)
  • mu = 0.01, tau = 1.0e-6, ntaps = 2000, nDown = 16
  • nDelay = 5 and nDelay = 7 both work (may not be so sensitive on delay at low frequencies)
  • Main changes: filter bank on the PEM channels (ASS_TOP_PEM_## filters: 0.1:0, 1:, Notch24, AA32)
  • Added the AI800 filter for upsampling in MC1 (should not matter)

 Matt suggested playing with the emphasis (EMPH) filters to cancel noise in different frequency bands.

 

Attachment 1: OAF_15JAN2010.png
OAF_15JAN2010.png
  2515   Fri Jan 15 11:21:05 2010 josephbUpdateComputersMegatron and tst model for ETMY

The tst model wasn't compiling this morning due to some incorrect lines in the RfmIOfloat.pm file located in /home/controls/cds/advLIgo/src/epics/util/lib file on megatron. 

The error was "Undefined subroutine &CDS::RfmIOfloat::partType called at lib/Parser2.pm line 354, <IN> line 3363."

I changed RfmIO to RfmIOfloat on lines 1 and 6.
Basically the first 6 lines are now

package CDS::RfmIOfloat;
use Exporter;
@ISA = ('Exporter');

sub partType {
        return RfmIOfloat;
}

The tst now compiles.  At the moment, I believe we should be able to switch megatron in for ETMY and attempt to lock the arm.  The whitening/dewhitening filters are still not automatically synced in software and hardware, but I don't think that should prevent locking.

  2514   Thu Jan 14 11:44:06 2010 josephbSummaryComputersMemory locations for TST model for ITMY

The main communications data structure is RFM_FE_COMMS, from the rts/src/include/iscNetDsc40m.h file.  The following comments regard sub-structures inside it.  I'm looking at all the files in /rts/src/fe/40m to determine how the structures are used, or if they seem to be unnecessary.

The dsccompad structure is used in the lscextra.c file.  I am assuming I don't need to add anything fo the model for these.  They cover from 0x00000040 to 0x00001000.

FE_COMMS_DATA is used twice, once for dataESX (0x00001000 to 0x00002000), and once for dataESY (0x00002000 to 0x00003000).

Inside FE_COMMS_DATA we have:

status and cycle which look to be initialized then never changed (although they are compared to).

ascETMoutput[P,Y], ascQPDinput are all set to 0 then never used.

qpdGain is used, and set by asc40m, but not read by anything.  It is offset 114, so in dataESX its 4210 (0x00001072), and in dataESY its (0x00002072)

All the other parts of this substructure seem to be unused.

daqTest, dgsSet, low1megpad,mscomms seem unused.

dscPad is referenced, but doesn't seem to be set.

pCoilDriver is a structure of type ALL_CD_INFO, inside a union called suscomms, inside FE_COMMS_Data, and is used.  In this structure, we have:

extData[16], an array of DSC_CD_PPY structures, which is used.  Inside extData we have for each optic (ETMY has an offset of 9 inside the extData array):

Pos is set in sos40m.c via the line pRfm->suscomms.pCoilDriver.extData[jj].Pos = dsp[jj].data[FLT_SUSPos].filterInput;   Elsewhere, Pos seems to be set to 1.0

Similarly, Pit and Yaw are set in sos40m, except with FLT_SUSPitch and FLT_SUSYaw, and being set elsewhere to 1.1, 1.2.  However, these are never applied to the ETMX and ETMY optics (it goes through offests 0 through 7 inclusive). 

Side is set 1.3 or 1.0 only, not used.

ascPit , ascYaw, lscPos are read by the losLinux.c code, and is updated by the sos40m.c code. For ETMY, their respective addresses are: 0x11a1c0, 0x11a1c4, 0x11a1c8.

lscTpNum, lscExNum, seem to be initialized, and read by the losLinux.c, and set by sos40m.c.

modeSwitch is read, but looks to be used for turning dewhitening on and off. Similarly dewhiteSW1R is read and used. 

This ends the DSC_CD_PPY structure.

lscCycle, which is used, although it seems to be an internal check.

dum is unused.

losOpLev is a substructure that is mostly unused.  Inside losOpLev, opPerror, opYerror, opYout seem to be unused, and opPout only seems ever to be set to 0.

Thats the end of ALL_CD_INFO and pCoilDriver.

After we have itmepics, itmfmdata, itmcoeffs, rmbsepics,...etymyepics, etmyfmdata,etmycoeffs which I don't see in use.

We have substructure asc inside mcasc, with epics, filt, and coeff char arrays. These seem to be asc and iowfsDrv specific.

lscIpc, lscepics, and lscla seems lsc specific,

The there is lscdiag struct, which contains v struct, which includes cpuClock, vmeReset, nSpob, nPtrx, nPtry don't seem to be used by the losLinux.c.

The lscfilt structure contains the FILT_MOD dspVME, which seems to be used only by lsc40m.

The lsccoeff structure contrains the VME_COEF pRfmCoeff, which again seems to only interact in the lsc code.

Then we have aciscpad, ascisc, ascipc, ascinfo, and mscepics which do not seem to be used.

ascepics and asccoeff are used in asc.c, but does not seem to be referenced elsewhere.

hepiepics , hepidsp, hepicoeff, hepists do not appear to be used.

 

 

 

 

 

 

  2513   Wed Jan 13 12:03:00 2010 AlbertoUpdateABSLMeasurement now running. Please be careful

At the moment I'm running a measurement on the PRC and I'm planning to leave it going for the time we'll be at the 40m meeting.

Please be careful in the lab. Thank you.

  2512   Wed Jan 13 12:01:06 2010 AlbertoUpdateComputersc1dcuepics, c1lsc rebooted this morning
Since last night the alignemtn scripts couldn't work.
c1lsc wasn't working properly because attempts to lock the X arm would try to control ETMY and attempts of locking the Y arm, wouldn't actuate any optics.
Also, another sign of a malfunctioning c1lsc was that one of the LSC filter modules, FM6, couldn't get loaded properly. It looked like only half loaded on the LSC MEDM screen.
On the other hand, plotting the trend of the last month, c1lsc's CPU didn't look more loaded that usual.
 
Rebooting and restarting C1lsc wasn't enough and I also had to reboot c1dcuepics a couple of times beforse getting things back to work.
  2511   Tue Jan 12 14:28:01 2010 steveSummaryEnvironmentlab temp of 7 years

Quote:

Quote:

Rana noticed that recently the temperature inside the lab has been a little bit too high. That might be causing some 'unease' to the computers with the result of making them crash more often.

Today I lowered the temperature of the three thermostats that we have inside the lab by one degree:
Y arm thermostat: from 71 to 70 F
X arm thermostat: from 70 to 69 F
Aisle thermostat: from 72 to 71 F.

For the next hours I'll be paying attention to the temperature inside the lab to make sure that it doesn't go out of control and that the environment gets too cold.

 Today the lab is perceptibly cooler.

The temperature around the corner is 73 F.

 

Attachment 1: labtemp7y.png
labtemp7y.png
  2510   Tue Jan 12 13:24:50 2010 HaixingUpdateSUSQuadrant Magnetic Levitation

I have tried to make the quadrant magnetic levitation work but unfortunately I did not succeed. During the experiment, I have made

the following changes to the circuit and setup:

 

(1) I added small resistors (6K) in parallel to R11, R23, R35 and R47 (indicated in the following schematics)  to increase

the control bandwidth from 20 Hz  to 80 Hz.

 

 

schmematic.png

 

(2) I changed RLED1, RLED2, RLED3, RLED4 from 2.2K to 1.5K  in the LED driver such that the current of the

LED increases and in turn the displacement sensitivity increases.

 

(3) I changed R51 and R51 (in the differencing block for PD1 and PD2) from 5K to 1 K. Correspondingly,

I increased R52 and R54 from 5K to 50K. This changes increase the gain in the differential control by a

factor of 50, which compensates the gain loss after increasing the control bandwidth.

 

 (4) The trim pots in the coil drive block have the following values: 100K for pot1 and pot4, 1K fro pot 2 and pot3.

To increase the gain, I replaced R17, R30, R31, R41 by 102 Om resistors (we run out of 100 Om chip resistors.)

 

(5) I wrapped the OSEM flags by plastic tubes to block the light from the LED more efficiently. This also removed

the changes of the photocurrent in the photodetector when the levitated plate moves horizontally.

 

Possible issues that cause the setup not working at the moment:

 

(1) The feedback gain could be probably still not enough. During the experiment, I can't feel any force changes when the

flags crossing the zero point. The error signals and control signal has the right sign.

 

(2) The levitated weight may be not enough and the working point is below the extremum of the DC attracting force.

This could give rise to a large negative spring which requires unreasonable feedback gain to compensate.

 

(3) The DC attracting force between the magnets are differing each other too much (mismatch) and can't

be compensated by the coil driving force.

 

(4) The control bandwidth may be still not  large enough. Initially my design was 100 Hz, but I forgot to divide

the angular frequency by 2pi and the resulting circuit has a bandwidth of 20 Hz. Later I increase it up to 80 Hz

by changing the resistors as mentioned before.

 

(5) The polarization of the coil could have a wrong sign. I have checked with Gauss meter, but still the absence

of zero-point crossing force change makes me worry about this.

 

For continuation of this work, I will finish writing my document and summarize all the results and outline what

needs to be done in the future. If everything goes well, I will be back in June and can spend more time on this

experiment. I can also work with the summer students together on this project.

  2509   Tue Jan 12 11:34:26 2010 josephbUpdatePEMAllegra dataviewer

Quote:

So that we can use both Guralps for Adaptive stuff, and so that I can look at the differential ground motion spectra, I've reconnected the Guralp Seismometers to the PEM ADCU, instead of where they've been sitting for a while connected to the ASS ADC.  I redid the ASS.mdl file, so that the PEM and PEMIIR matricies know where to look for the Gur2 data.  I followed the 'make ass' procedure in the wiki.  The spectra of the Gur1 and Gur2 seismometers look pretty much the same, so everything should be all good.

There's a problem with DataViewer though:  After selecting signals to plot, whenever I hit the "Start" button for the realtime plots, DataViewer closes abruptly. 

When I open dataviewer in terminal, I get the following output:

allegra:~>dataviewer
Warning: communication protocol revision mismatch: expected 11.3, received 11.4
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: communication protocol revision mismatch: expected 11.3, received 11.4
msgget: No space left on device
allegra:~>framer4 msgget:msqid: No space left on device

Does anyone have any inspiration for why this is, or what the story is?  I have GR class, but I'll try to follow up later this afternoon.

 This problem seems to be restricted to allegra.  Dataviewer works fine on Rosalba  and op440m, as well as using ssh -X into rosalba to run dataviewer remotely.  DTT seems to work fine on allegra.  The disk usage seems no where near full on allegra.  Without knowing which "device" its refering to (although it must be a device local to allegra), I'm not sure what to look at now. 

I'm going to do a reboot of allegra and see if that helps.

Update:  The reboot seems to have fixed the issue.

 

 

 

 

  2508   Tue Jan 12 09:37:05 2010 AlbertoUpdateABSLIFO available

I finished measuring the AbsL for this morning. The IFO is again available.

Please don't mess up with the interferometer though. I'll be back in a couple of ours

  2507   Tue Jan 12 09:14:52 2010 steveSummaryGeneralScattering Measurements of 35W Beam Dumps

 

 What was the power level, polarization and beam size at beam trap?

  2506   Mon Jan 11 21:49:17 2010 JenneUpdateABSLMeasurement running

Quote:

Leaving for dinner. Back in ~1hr.

I left a measurement running. Please don't interfere with it till I'm back. Thanks.

 Per Alberto's instructions, I have closed the shutter on his laser so that the Adaptive Team can play with the Mode Cleaner.

  2505   Mon Jan 11 19:36:13 2010 AlbertoUpdateABSLMeasurement running

Leaving for dinner. Back in ~1hr.

I left a measurement running. Please don't interfere with it till I'm back. Thanks.

  2504   Mon Jan 11 16:59:14 2010 AlbertoUpdateABSLInterferometer Busy

I'm currently running a measurement on the PRC.

Please don't interfere with the IFO until it is done. Talk with Alberto if you've been intending to work inside the lab.

Thank you.

  2503   Mon Jan 11 14:16:59 2010 JenneUpdatePEMGur2 cables reconnected to the PEM ADCU

So that we can use both Guralps for Adaptive stuff, and so that I can look at the differential ground motion spectra, I've reconnected the Guralp Seismometers to the PEM ADCU, instead of where they've been sitting for a while connected to the ASS ADC.  I redid the ASS.mdl file, so that the PEM and PEMIIR matricies know where to look for the Gur2 data.  I followed the 'make ass' procedure in the wiki.  The spectra of the Gur1 and Gur2 seismometers look pretty much the same, so everything should be all good.

There's a problem with DataViewer though:  After selecting signals to plot, whenever I hit the "Start" button for the realtime plots, DataViewer closes abruptly. 

When I open dataviewer in terminal, I get the following output:

allegra:~>dataviewer
Warning: communication protocol revision mismatch: expected 11.3, received 11.4
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: Not all children have same parent in XtManageChildren
Warning: communication protocol revision mismatch: expected 11.3, received 11.4
msgget: No space left on device
allegra:~>framer4 msgget:msqid: No space left on device

Does anyone have any inspiration for why this is, or what the story is?  I have GR class, but I'll try to follow up later this afternoon.

ELOG V3.1.3-