40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 311 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  13924   Thu Jun 7 10:26:36 2018 keerthanaUpdatePSLobserving the resonance signal corresponding to the injected frequency.

(Johannes, Koji, Keerthana)

The PLL loop ensures that the frequency difference between the PSL laser and the AUX laser is equal to the frequency we provide to the Local Oscillator (LO) with the help of a Marconi. Only a small pick off part of both the AUX and PSL lasers are going to the PLL loop. The other part of both the lasers are going to the interferometer. Before entering into the optical fibre, the AUX laser passes through an AOM which changes its frequency by an amount of 80MHz. When the PLL is locked, the frequency coming out of the PLL will be equal to the frequency set up in the Marconi (fm). When it passes through AOM, the frequency becomes fdiff = fm ±80 MHz. If this frequency beam and the PSL laser beam is aligned properly, and if this frequency is equal to the product of an integer and the free spectral range of the cavity, this will resonate in the cavity.  Then we expect to get a peak in the ETM transmission spectrum corresponding to the frequency we injected through the optical Fibre.

Through out the experiment we need to make sure that the PSL is locked. Thus, the signal detected by the photo detector when only PSL is resonating inside the cavity, act as a DC signal. Then we give a narrow scan to the Marconi. When fdiff = N*FSRy this condition is satisfied, we will observe a peak in the output. Here FSRy  is the free spectral range of the cavity which is approximately equal to 3.893 MHz.

Yesterday afternoon, Johannes, Koji and myself tried to observe this peak. We aligned the cavity by observing the output signal from the AS100 photo detector. We made the alignment in such a way that the intensity output getting from this photo detector is maximum. We used a Spectrum analyser to see the output. After that we connected a photo detector to collect the YEND transmission signal from the ETM mirror. We used a lens to focus this directly to the photodetector. Then we connected this photodetector to the spectrum analyser, which was located near the AS table. We took a large cable to meet this purpose. But still the cable was not lengthy enough, so we joined it with another cable and finally connected it with the spectrum analyser. Then we gave a scan to the Marconi from 51 MHZ to 55 MHz. We repeated this experiment with a scan of 55 MHz to 59 MHz also. We repeated this a few times, but we were not able to see the peak.

We assume that this can be because of some issue with the alignment or it can be because of some issue with the photo detector we used. We would like to repeat this experiment and get the signal properly.

I am attaching a flow chart of the setup and also a picture of the mirrors and photo detector we inserted in the Y-End table.

 
Attachment 1: photodetector_alignment.jpg
photodetector_alignment.jpg
Attachment 2: design1.PNG
design1.PNG
  13930   Thu Jun 7 22:36:09 2018 not keerthanaUpdatePSLobserving the resonance signal corresponding to the injected frequency.

I worked a bit on the PSL table today

  13931   Fri Jun 8 00:36:54 2018 gautamUpdatePSLobserving the resonance signal corresponding to the injected frequency.

It isn't clear to me in the drawing where the Agilent is during this measurement. Over 40m of cabling, the loss of signal can be a few dB, and considering we don't have a whole lot of signal in the first place, it may be better to send the stronger RF signal (i.e. Marconi pickoff) over the long cable rather than the weak beat signal from the Transmission photodiode. 

  4131   Tue Jan 11 01:05:29 2011 kiwamuUpdateLSCobtained Xarm PDH signal

[Jenne, Zach, Kiwamu]

 

 We made some efforts to lock the X arm cavity with the infrared beam.

We eventually obtained the PDH signal from a photo diode at AS port, we are still in the mid way of the lock.

The PDH signal now is going into c1lsc's ADC.

We have to make sure which digital channel corresponds to our PDH signal,

 

(what we did)

- split the LO signal, which comes from a Marconi, just before the EOM into two path.

     One is going to the EOM and the other is going to the AP table for the demodulation, The driving frequency we are using is 11MHz.

- put RF amplifiers to make the RF signal bigger. The raw signal was small, it was about ~-50 dBm in the spectrum analyzer.

   So we connected two ZLN amplifiers. Now the RF signal is at about 0 dBm

- connected the LO and RF signals to a mixer.  Additionally we put a 9.5-11.5 MHz bandpass filter at the LO path since there was some amounts of 29.5MHz due to the RF reflection at the EOM resonant box.

     After a low pass filter by SR560 the signal shows typical PDH behaviors.

- strung a BNC cable which connects the demodulated signal and c1lsc.

    In order to connect the signal to the current working ADC, we disconnected AS166_I from a whitening board and plug our cable on it.

- tried checking the digital signal but we somehow couldn't configure DAQ setting, So actually we couldn't make sure which channel corresponds to our signal.

 

  15026   Thu Nov 14 23:56:18 2019 ranaUpdateLSCoff the bad Violin filters

We turned off many excessive violin mode bandstop filters in the LSC.

Due to some feedforward work by Jenne or EQ some years ago, we have had ~10 violin notches on in the LSC between the output matrix and the outputs to the SUS.

They were eating phase, computation time, and making ~3 dB gain peaking in places where we can't afford it. I have turned them off and Gautam SDF safed it.

Offensive BS shown in brown and cooler BS shown in blue.

To rotate the DTT landscape plot to not be sideways, use this command (note that the string is 1east, not least):
pdftk in.pdf cat 1east output out.pdf

Attachment 1: out.pdf
out.pdf
  15028   Fri Nov 15 11:58:12 2019 gautamUpdateLSCoff the bad Violin filters

The clue was that the loop X arm POX loop looked to have low (<3dB)) gain margin around 600 Hz (and again at 700 Hz). Attachment #1 shows a comparison of the OLTF for this loop (measured using the IN1/IN2 method) before and after our change. We hypothesize that one of the violin filters that were turned off had non-unity DC gain, because I had to lower the loop gain by 20% after these turn-offs to have the same UGF. I updated the snap files called by the arm locking scripts.

I think I caught all the places where the FM settings are saved, but some locking scripts may still try and turn on some of these filters, so let's keep an eye on it.

Quote:

We turned off many excessive violin mode bandstop filters in the LSC.

Attachment 1: violinFix.pdf
violinFix.pdf
Attachment 2: newViolinConfig.png
newViolinConfig.png
  1869   Sat Aug 8 17:23:29 2009 ranaUpdatePEMoffensive 2 Hz sine wave removed

Friday, we were seeing a 2 Hz harmonic series in all of the PEM channels. Today I found that some bad person had put in a 4V (!) signal into one of the channels with a signal generator. The generator was also sneakily stuck way back inside the DCU rack. NO SECRET SIGNAL INJECTIONS!

Since the ADC has a 2Vpk range, this was saturating and putting in harmonics in all the adjacent channels. I disconnected it and turned off the function generator.

  15193   Thu Feb 6 16:14:44 2020 ranaUpdateGeneraloffice area temperature

I changed the office area thermostate near Steve's desk from 68F to 73F today. Please do not change it.

If anyone from facilities comes to adjust something, please put the details in the elog on the same day so that we can know to undo that change rather than chase down other drifts in the system.

  15196   Fri Feb 7 02:41:28 2020 KojiUpdateGeneraloffice area temperature

Not sure what's wrong, but the workstation desk is freezing cold again and the room temp is 18degC (64degF).

  6642   Fri May 11 23:33:41 2012 DenUpdateAdaptive Filteringoffline vs online

I've compared offline Wiener filtering with online static + adaptive filtering for MC_F with GUR1_XYZ and GUR2_XYZ as witness signals

off_on.jpg

Note: online filter works up to 32 Hz (AI filter at 32 Hz is used). There is no subtraction up from this frequency, just MC_F was measured in different times for online and offline filtering. This difference in MC_F in frequency range 20-100 Hz showed up again as before with microphone testing.  One can see it in 1 minute. Smth is noisy.

Reasons why online filter is worse then offline:

1. FIR -> IIR conversion produces error. Now I'm using VECTFIT approximation with 16 poles (splitting into 2 filter banks), this not enough. I tried to use 50 and split them into 5 filter banks, but this scheme is not working: zpk -> sos conversion produces error and the result filter works completely wrong.

2. Actuator TF. VECTFIT works very good here - we have only 1 resonance. However, it should be measured precisely.

3. Account for AA and AI filters that rotate the phase at 1-10 Hz by ~ 10 degrees.

  5806   Fri Nov 4 05:24:56 2011 kiwamuUpdateLSCoffset introcuded in MC and IFO-configure script modified

[Offsets in MC]

 I have introduce an offset in MC2 PIT because the PZT1 again started railing.

Right now the PZT1 EPICS value is within the range happily.

Please keep this MC eigen axis as a nominal configuration.

 

[IFO-configure script]

 I have modified the IFO configure scripts such that XARM and YARM are locked with POX11 and POY11 respectively.

A big advantage in use of POX and POY is that we don't need to misalign ITMs when we align each arm.

Those scripts are now available from the C1IFO_CONFIGURE screen as usual.

  11732   Wed Nov 4 20:16:58 2015 yutaroUpdateElectronicsoffset voltage vs. gain of common mode servo

At 1Y2 rack, I measured offset voltage of the common mode servo (D040180-B) with the gain of it varied.

For now, all signal cables that come into or go out of the common mode servo are not plugged.

 

I will upload the data I took and report the result later.

  11737   Thu Nov 5 10:48:21 2015 yutaroUpdateElectronicsoffset voltage vs. gain of common mode servo

I report the results of the measurement to know how offset voltage of common mode servo changes when the gain is changed.

 

- Motivation: If discontinuous change of the offset happens when we change the gain, it could cause saturation somewhere and so make the length control down. So, we want to estimate effect of such discontinuous change.

 

- Method: In 1 (or In 2) was terminated with 50 ohm, and the output voltage at Out 2 was measured with a multimeter (D040180-B).

 

- Results are shown below. Acquired data are attached in .zip.

The upper shows input equiv. offset. The lower shows offset measured at Out 2.

As for both In1 and In2, strange behaviors can be seen between -17 dB and -16 dB.

This is because 5 amplifiers (or attenuators) are simultaneously enabled/disabled here. Similar situation occurs every change of 8 dB gain. 

Attachment 2: offsets.zip
  9968   Sun May 18 14:36:04 2014 denUpdateLSCoffsets in 3f and drmi stable lock on 1f

Eric, Den

We noticed that PRMI RIN is high when the cavity is locked on RELF33 I&Q signals. We compared the level of power fluctuations when PRMI was locked using REFL11, REFL55 and REFL 33. Attached plot "prmi_rin" shows the spectra.

Then we excited PRM and measured length to RIN coupling when PRMI was locked on REFL33 I&Q. DC offset of PRCL is only 3%. But MICH offset seems to be ~nm. When we gave offset of -15 cnts to the servo, power fluctuations improved by a factor of few.

Then we looked at DRMI. It seems that SRC macroscopic length is off but we still could lock it stably. To account for macroscopic length detuning we had to rotate REFL55 phase from 25 degrees to 50 degrees. Power at AS port increased by factor of ~2 compared to PRMI configuration. SPOP18 is decreased only by 30%. Attached plot "drmi_power" shows POP18, POP90, POPDC and ASDC in PRMI and DRMI configurations.

Plot "src_ol" shows srcl OL transfer function. UGF is 70 Hz. We have also centered SRM OL and copied the servo filters from PRM, gains are set to keep UGF at ~0.1 Hz and 7 Hz

This is a more detailed procedure:

1. Phase: REFL11: 19 degree, REFL55: 50 degrees (25 degrees for PRMI configuration)

2. Input matrix:

PRCL   0.15 0 0 REFL11I
MICH = 0 0.15 0 REFL55Q
SRCL   -0.09 0 1 REFL55I

3. Servo parameters:

PRCL: gain = -0.02, FM4,5 + trigger FM2,3,6,9

MICH: gain = 0.8, FM4,5 + trigger FM2

SRCL: gain = 0.25, FM4,5 + trigger FM2,3

4. Triggering:

signal is SPOP22 , levels 40:25

Attachment 1: prmi_rin.pdf
prmi_rin.pdf
Attachment 2: drmi_power.png
drmi_power.png
Attachment 3: src_ol.pdf
src_ol.pdf
  14435   Tue Feb 5 10:22:03 2019 chubUpdate oil added to RP-1 & 3

I added lubricating oil to roughing pumps RP1 and RP3 yesterday and this morning.  Also, I found a nearly full 5 gallon jug of grade 19 oil in the lab.  This should set us up for quite a while.  If you need to add oil the the roughing pumps, use the oil in the quart bottle in the flammables cabinet.  It is labeled as Leybold HE-175 Vacuum Pump Oil.  This bottle is small enough to fill the pumps in close quarters.

  10560   Thu Oct 2 14:36:52 2014 steveUpdatePEMoil drops on vertex crane

Quote:

 

 KroneCrane Fred inspected and certified the 3 40m cranes for 2014. The vertex crane crane was load tested at fully extended position.

 Small oil drops were found during prevent inspection of the vertex crane. They were wiped off. It took 231 days to grow this size.

Attachment 1: VertexOilDrops.jpg
VertexOilDrops.jpg
  12871   Mon Mar 6 16:32:36 2017 SteveUpdateGeneralold NPRO

16 years old Lightwave NPRO M126-1064-700, sn 415 power output is tripping continously to zero.

The Lightwave Controller 125/126-OPN-POS sn516 was used in this test. Settings were lowered to close to nominal values without any success.

One can not determine what is broken: head or controller. This NPRO head was under Manasa's desk.
 

  4866   Thu Jun 23 10:35:12 2011 steveUpdateComputersold computers leaving the lab

Rod Luna picked up these computers for Larry Wallace yesterday: Dell Inspiron 530, Dell Dimension 4600 and SunBlade 1000

Attachment 1: P1070905.JPG
P1070905.JPG
Attachment 2: P1070904.JPG
P1070904.JPG
Attachment 3: blade1000.JPG
blade1000.JPG
  12162   Thu Jun 9 15:14:46 2016 jamieUpdateCDSold fb restarted, test of new daqdon fb1 aborted for time being

I've restarted the old daqd on fb until I can figure out what's going on with the symmetricom driver on fb1.

Steve:  Jamie with hair.... long time ago
 

Attachment 1: Jamie.jpg
Jamie.jpg
  10435   Thu Aug 28 08:31:16 2014 SteveUpdateGeneralone good day
Attachment 1: 1goodDay.png
1goodDay.png
Attachment 2: 1gooday.png
1gooday.png
  13631   Tue Feb 13 21:22:44 2018 SteveUpdateSEIone load cells tested

Gautam and Steve,

The "called 225 lbs" steel crane load measured right on 102 kg

The trick to the measurment to maintain 1 mm gap to the central cilynder of the load cell.

The lead plate stabilized the large load.


gautam: some additional notes:

  1. the wiring on the Omega controller unit as given to us was wrong - I had to fix this on the D-sub connector in order to get the load cell to work. something to check for the other units.
  2. the main difficulty in doing this calibration run was that the readback is very sensitive to tilts of the load relative to the sensor.
  3. the problem is complicated by the fact that the load cell itself does not have a flat surface - it has a ring that protrudes above the flat face of the cylindrical load cell by a few mm as Steve mentioned.
  4. so in order to measure the weight of our stacks, we have to mitigate this problem and ensure that the full load of the stack is normally incident on the load cell - if the load cell itself is somehow torqued during the measurement because of the distribution of the load on it being uneven, we get an inaccurate measurement.
  5. In this calibration measurement, we think the error is <1% (true mass is 102kg, we measure 104kg on the meter which seems reasonable as the sum of the donut + lead plate)

Attachment 1: as_measured_102kg.jpg
as_measured_102kg.jpg
Attachment 2: sensor.jpg
sensor.jpg
Attachment 3: 1500lbs_load__cell.jpg
1500lbs_load__cell.jpg
  2089   Tue Oct 13 10:31:11 2009 ZachUpdatePSLone more time

I am at the PSL table taking what is hopefully the last set of pictures for the diagram. Woohoo.

  2090   Tue Oct 13 10:50:58 2009 ZachUpdatePSLone more time

Quote:

I am at the PSL table taking what is hopefully the last set of pictures for the diagram. Woohoo.

 I'm out, HEPAs are back at 20%.

  7708   Tue Nov 13 21:05:35 2012 DenUpdateAdaptive Filteringonline and simulation

For a last few days I've been working on oaf and simulink model to simulate it. First I did online subtraction from MC when MC_L path was enabled. Inside my code I've added a sum of squares of filter coefficients so we can monitor convergence of the filter.

coeff.png     online.png

To to this I've measured path from OAF output to input without AA and AI filters. Then made a vectfit using 2 poles and zeros. Foton command

zpk( [-2.491928e+03;5.650511e-02], [-4.979872e+01;-3.278776e+00], 6.011323e+00)

mag.png    phase.png

My simulink model consists of 3 parts:

  • cavity with seismic noise at low frequencies, 1/f^2 noise at medium frequencies and white noise at high frequencies
  • this cavity is locked using feedback compensation filters that we use to lock arms
  • locked cavity with adaptive filter

Adaptive filter in the model uses online c-code. It is connected to simulink block through an S-function. Sampling frequency of the model is 10 kHz. It works fairly fast - 1 sec of simulation time is computed in 1 sec.

overview.png       af.pngsim.png  sim_coeff.png

I've tested FxLMS algorithm and MFxLMS algorithm that is faster. I plan to test 2 iir adaptive algorithms that are already coded.

  7042   Thu Jul 26 21:31:44 2012 DenUpdatedigital noiseonline biquad works

Quote:

   Still I do not like huge (2n+1) harmonics in the output of the biquad filter, I do not get them in the simulations. They are absent in the time series as well. So this is not a psd-estimation effect. 

 Excitation generator created these harmonics. When I applied low-pass butterworth filter, I've got the result of online filtering close to simulations. On the second graph blue is biquad filter output spectrum, red corresponds to DF2. 1 Hz sin wave was filtered with a notch filter of Q=100, depth=300 at 1 Hz.

df2_bqf_lp.png    df2_bqf_lp_spec.png

  6297   Sat Feb 18 18:29:38 2012 DenUpdateAdaptive Filteringonline filtering

I tried to filter MC_F from seismic noise measured by GUR1 seismometer. I've used 8000 tap filter, downsample ratio=8, delay=1. In the Figure the output of the filter is presented with MC_F signal.

output.pdf

We can see that output is close to the MC_F, but the phase for some reason is not zero. It should not be at 1 Hz - 10 Hz due to the actuator. But below these frequencies I do not see any reasons for the output phase to differ from MC_F phase. But it is possible, the phase of the actuator is evaluated very rough and the adaptive filter can't match it.

  6241   Tue Jan 31 17:13:49 2012 steveUpdateIOOonly the PSL laser is off

 

The 2W PSL laser is turned off.  The danger laser lights are not illuminated at the entry doors because of malfunctioning electronic circuit!!!

Laser safety glasses are still required!  Other lasers are in operation!

  111   Fri Nov 16 14:11:26 2007 tobinUpdateComputersop140
Alan called to say that Phil Ehrens will be coming by to take op140 off our hands.
  112   Fri Nov 16 14:31:43 2007 tobinUpdateComputersop140 disks
Phil Ehrens stopped by and took op140's disks.
Attachment 1: DSC_0173.JPG
DSC_0173.JPG
  10084   Fri Jun 20 19:07:44 2014 ranaUpdateComputer Scripts / Programsop340m DNS

I had forgotten to fix the DNS setup on op340m and so our slow, perl, PID loops for the laser were not running well (and that's why the FSS-FAST has been saturating).

I edited /etc/resolv.conf on there and then did /usr/sbin/reboot as super-user.

op340m:~>more /etc/resolv.conf
domain martian
nameserver 192.168.113.104
nameserver 131.215.125.1
nameserver 131.215.139.100
nameserver 131.215.9.49
op340m:~>date
Fri Jun 20 19:06:37 PDT 2014

The FSSSlowServo.pl now seems to be holding the NPRO PZT to ~6 V. I twiddled the PID settings a little bit to make sure nothing was squirrelly. Seems OK. Time constant of the loop is ~1 minute.

As a reminder, op340m runs our autoburt for all the FE machines, VME IOCs, does the watchdog threshold rampdown, and also the RefCav and NPRO temperature control.

  10095   Tue Jun 24 22:46:15 2014 ericqUpdateComputer Scripts / Programsop340m crons

Quote:

The FSSSlowServo.pl now seems to be holding the NPRO PZT to ~6 V. I twiddled the PID settings a little bit to make sure nothing was squirrelly. Seems OK. Time constant of the loop is ~1 minute.

As a reminder, op340m runs our autoburt for all the FE machines, VME IOCs, does the watchdog threshold rampdown, and also the RefCav and NPRO temperature control.

 We had fiddled with the scripts/general/scripto_cron script to try and get the MC auto locker working on ottavia, but in doing so broke op340m's reliance on it to run it's cron jobs, like FSSSlowServo.

I've reverted scripto_cron to its original state, and the FSS slow servo starts up again.  

However, scripts like this that we want to always have on seem to be a better fit, to me, for the init system, like we do with daqd and nds on the FB. op340m's inittab looks different than what I'm used to, so I'm not making any changes; this is just a thought. 

MC autolocker is still being ran from an Ottavia GUI terminal; I'll try to get it consistently running on megatron, as suggested in  ELOG10039, now that caget/caput issues seem to be sorted. 

Addendum: I've changed the MC auto locker script to have megatron as its host. Haven't yet gotten it to run automatically; it's running in a detached tmux terminal. I'll finish it up tomorrow. 

  11624   Mon Sep 21 00:51:36 2015 ranaUpdateGeneralop340m, autoburt cron =? megatron

I modified the perl script which does our hourly autoburt so that it can run on megatron instead of op340m (old Solaris machine). Nothing major, just some path stuff. That was the last function of op340m that I know of, so after a week of watching this we ought to be able to power it off and send it to e-waste.

Seems to work so far. It complains about some models that aren't running but mostly it reports successful snapshot taking based on the .req files.

Unfortunately, it seems that its only doing the new target directory, so its missing all of our old VME machines which still use the /cvs/cds/caltech/target area.

But I think Gautam and Jamie and Aidan have volunteered to start our slow controls upgrade by moving the EX slow controls to Acromag and into the new target area. We ought to modify the CRON to point at the old directory for now, but its a temporary fix hopefully.

  625   Wed Jul 2 17:19:03 2008 JohnSummaryComputersop440m - shutdown and restarted
After 160days op440m was getting a little slow.
  1637   Mon Jun 1 14:33:42 2009 robConfigurationComputer Scripts / Programsop540m Monitor added to web status

I added op540m's display 0 (the northern-most monitor in the control room) to the MEDM screens webpage: https://nodus.ligo.caltech.edu:30889/medm/screenshot.html

 

Now we can see the StripTool displays that are usually parked on that screen.

 

 

  3476   Fri Aug 27 11:24:13 2010 JenneOmnistructureComputersop540m dead

I think op540m has finally bitten the dust.  I noticed that both of its screens were black, so I assumed that it had crashed due to known graphics card issues or something.  But upon closer inspection, it is way more dead than that.  I checked that it does have power (at least the power cable is securely plugged in at both ends, and the power strip its on is successfully powering several other computers), but I can't make any lights or anything come on by pressing the power button on the front of the computer tower.

Immediate consequences of op540 not being operational are the lack of DMT, and the lack of Alarms. 

Joe is doing an autopsy right now to see if its really dead, or only 'mostly dead'.

EDIT: Joe says maybe it's the power supply for the computer.  But he can't turn it on either.

  3061   Wed Jun 9 21:05:44 2010 ranaSummaryComputersop540m is not to be used

This is a reminder (mainly for Steve, who somehow doesn't believe these things) that op540m is not to be used for your general pleasure.

No web, no dataviewer, no DTT. Using these things often makes the graphical X-Windows crash. I have had to restart the StripTool, our seismic BLRMS and our Alarms many times because someone uses op540m, makes it crash, and then does not restart the processes.

Stop breaking op540m, Steve!

  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.

  3605   Fri Sep 24 16:31:35 2010 steveConfigurationGeneralopen frame- rack is moved

The squeezing open frame rack was moved from the south side of the PSL enclosure to the north side of the SP table.

AC power breaker is PC-2  #1

 

Attachment 1: P1060881.JPG
P1060881.JPG
  2246   Thu Nov 12 01:18:34 2009 haixingUpdateSUSopen-loop transfer function of mag levi system (comparison between simulink and measurement)

I built a Simulink model of the magnetic levitation system and try to explain the dip in the open-loop transfer function that was observed.

One can download the model in the svn. The corresponding block diagram is shown by the figure below.

 

block_diagram.png

Here "Magnet" is equal to inverse of the magnet mass. Integrator "1/s" gives the velocity of the magnet. A further integrator gives the displacement of the magnet.

 

Different from the free-mass response, the response of the magnet is modified due to the existence of the Eddy-current damping  and negative spring in the vertical

direction, as indicated by the feedback loops after two integrals respectively. The motion of the magnet will change the magnetic field strength which in turn will pick

up by the Hall-effect sensor. Unlike the usual case, here the Hall sensor also picks up the magnetic field created by the coil as indicated by the loop below the mechanical

part. This is actually the origin of the dip in the open-loop transfer function. In the figure below, we show the open-loop transfer function and its phase contributed by both

the mechanical motion of the magnet and the Hall sensor with the black curve "Total". The contribution from the mechanical motion alone is shown by the magenta curve

"Mech" which is obtained by disconnecting the Hall sensor loop (I rescale the total gain to fit the measurement data due to uncertainties in those gains indicated in the figure). 

The contribution from the Hall sensor alone is indicated by the blue curve "Hall" which  is obtained by disconnecting the mechanical motion loop. Those two contributions

have the different sign as shown by the phase plot, and they destructively interfere with each other and create the dip in the open-loop transfer function.

contribution_plot.png

In the following figure, we show the close-loop response function of the mechanical motion of the magnet.

 

mech_resp_plot.png

As we can see, even though the entire close loop of the circuit is stable, the mechanical motion is unstable around 10 Hz. This simply comes from the fact that

around this frequency, the Hall sensor almost has no response to the mechanical motion due to destructive interference as mentioned.

 

In the future, we will replace the Hall sensor with an optical one to get rid of this undesired destructive interference.

 

 

  1863   Fri Aug 7 18:06:24 2009 robOmnistructureVACopening V1 when PTP1 is broken

We've had a devil of a time getting V1 to open, due to the Interlock code. 

 

The short story is that if C1:Vac-PTP1_pressure > 1.0, the interlock code won't let you push the button to open V1 (but it won't close V1). 

 

PTP1 is broken, so the interlock was frustrating us.   It's been broken for a while, but this hasn't bitten us till now.

 

We tried swapping out the controller for PTP1 with one of Bob's from the Bake lab, but it didn't work. 

 

It said "NO COMM" in the C1:Vac-PTP1_status, so I figured it wouldn't update if we just used tdswrite to change C1:Vac-PTP1_pressure to 0.0.  This actually worked, and V1 is now open.  This is a temporary fix.

  1865   Fri Aug 7 19:55:08 2009 steveSummaryVACopening V1 when PTP1 is broken

The swapped in 307 convectron gauge controller  is very likely to have the  RS232 connection  wired differently from the old one.

PRP gauge has now the same error message as the PTP1:  "no comm"  I would look at RS232 wiring of the PRP gauge on the broken

controller and adapt the swapped in one to communicate. The PRP was reading 620 Torr before the swap.

  8514   Tue Apr 30 22:40:57 2013 JenneUpdateSUSoplev XY-plots reflect new calibration

Back when Gabriele was here, he and I implemented online calibration of the oplevs, into microradians.  A consequence of this is that all of the XY-plots on the medm screens were too small. 

I have gone through all the screens that I could think of (SUS_SINGLE, SUS_SINGLE_OPTLEV_SERVO, OPLEV_MASTER, OPLEV_SUMMARY, OPLEV_SUMMARY_SMALL_SCALE, IFO_OVERVIEW) and made the range of the XY-plots +/- 100, rather than the old scale of +/-1. 

I have also added red boxes behind the numbers on many (but not yet all) of these screens, so that you can see when (a) the oplev sum is too low, or (b) either the pit or yaw value is over 50 microradians. 

While I was putzing around on the IFO overview screen, I also made the oplev sum numbers clickable, with the related display being that optic's oplev servo screen.

  9152   Sun Sep 22 22:05:10 2013 ranaUpdateSUSoplev XY-plots reflect new calibration

The ETMX oplev signal looks kind of dead compared to the ETMY. It has no features in the spectra and the SUM is pretty low.

I noticed that the cal fields are still set to 1. To get it close to something reasonable, I calibrated it vs. the SUSPIT and SUSYAW values by giving it a step in angle and using 'tdsavg' plus some arithmetic.

OLPIT =  45 urads/ count

OLYAW = 85 urads / count

These are very rough. I don't even know what the accuracy is on the OSEM based calibration, so this ought to be redone in the way that Jenne and Gabriele did before.

The attached image shows the situation after "calibration" of ETMX. This OL system needs some noise investigation.

Attachment 1: noise.png
noise.png
  9188   Thu Oct 3 01:06:48 2013 rana, jenneUpdateSUSoplev XY-plots reflect new calibration

As another proof that sometime is ill with ETMX Optical Lever:

We scanned the ETMX bias in PIT using ezcastep and saw that the OL response is very screwy. In the attached, you can see that the ETMX SUSPIT signal shows that the actual motion is good and linear. In fact, our sus diagonalization is extermely good and there's almost no signal in SUSYAW.

Attachment 1: etmx_ol.png
etmx_ol.png
  9351   Tue Nov 5 19:55:12 2013 ranaUpdateSUSoplev XY-plots reflect new calibration

I used the same OSEM SUSPIT/YAW method as before to calibrate the ETMY optical lever signals. They were off by a factor of ~10.

ETMY Pitch     300  /  26    (old/new)     urad/counts

ETMY Yaw       300  /  31    (old/new)     urad/counts

These should be redone with the Kakeru / Ottaway arm cavity power technique if we want to get better than ~30% accuracy.

  1245   Thu Jan 22 12:08:59 2009 peteUpdateoplevsoplev calibration
Following the procedure described in Royal Reinecke's 2006 SURF report, I've calibrated the ETMY yaw oplev DOF. The idea is to sweep the mirror tilt, measuring the transmitted cavity power and the oplev error signal. The cavity power can be related to the mirror tilt in radians following D. Anderson APPLIED OPTICS, Vol. 23, No. 17, 1984.

I've made a simple matlab script which spits out the final number; it calls Royal's perl script to do the sweep. I get 420 microrad/ct for ETMY yaw. In 2006 Royal got 250 microrad/ct. Could something have changed this much, or is one of us wrong? I'll double check my procedure and do the other arm cavity oplevs, and describe it in detail when I have more confidence in it.

Kakeru and I plan to extend this to handle the PRM, SRM, and BS. One script to rule them all.
  8389   Tue Apr 2 15:58:40 2013 JenneUpdateSUSoplev calibration for ITMX, BS

[Jenne, Gabriele]

Optical lever calibrations:

ITMX pit calibration = -9.07 cts/mrad

ITMX yaw calibration = -12.33 cts/mrad

ITMX plot:opl_itmx.png

BS pit calibration = -22.86 cts/mrad

BS yaw calibration = -24.14 cts/mrad

BS plot:opl_bs.png

 

Method:  Similar to Manasa and Yuta's method last month.  We mounted each oplev QPD on a micrometer translation stage, centered the beam using the steering mirror, then used tdsavg to get 10 second averages of the _INMON channel for various settings of the micrometer stage.  For BS, we had to take out the PRM oplev to make room for the translation stage.  All QPDs were remounted in their original positions, within less than 1mm.  Measured the out-of-vac distances with the laser disto-meter, and the invac distances from the optic to the window from the CAD drawing.

Copying from other elog entries,

elog 8232:

We calibrated oplev for ITMY. Calibration factor for C1:SUS-ITMY_OL(PIT|YAW)_IN1 are;
  OLPIT: 6.29 +/- 0.11 counts/mrad
 
OLYAW: 5.74 +/- 0.09 counts/mrad

 

elog 8221:

We calibrated oplev for PRM. Calibration factor for C1:SUS-PRM_OL(PIT|YAW)_IN1 are;
  OLPIT: 15.6 +/- 0.3 counts/mrad
  OLYAW: 17.8 +/- 0.3 counts/mrad

  8390   Tue Apr 2 16:13:10 2013 ranaUpdateSUSoplev calibration for ITMX, BS

  Very good - now you need to just put the cal factor into the filter banks so that the PERROR and YERROR signals are in microradians all the time.

 

EDIT JCD:  In progress.

  8232   Tue Mar 5 17:09:30 2013 yutaUpdateSUSoplev calibration for ITMY

[Manasa, Sendhil, Yuta]

We calibrated oplev for ITMY. Calibration factor for C1:SUS-ITMY_OL(PIT|YAW)_IN1 are;
  OLPIT: 6.29 +/- 0.11 counts/mrad
 
OLYAW: 5.74 +/- 0.09 counts/mrad

Note that there was ~10% of coupling between pitch and yaw.
This is large considering statistical error, but I think this is from QPD mounted rotated (by ~5 deg).

Method:
  Same as in elog #8221.

Result:
 
moved in y: ITMY_PIT.png      moved in x: ITMY_YAW.png

micrometer    OLPIT          OLYAW
moved in y    3.14 +/- 0.05  0.27 +/- 0.03
moved in x   -2.87 +/- 0.04  0.17 +/- 0.03    (counts/mm)


  Measured the path length of ITMY oplev returning beam was 2000 +/- 20 mm. This gives you the calibration factors above.

  ~10 % coupling between OLPIT and OLYAW can be explained by QPD rotation by ~ 5 deg, which seems not unreasonable.

  8221   Mon Mar 4 16:46:31 2013 yutaUpdateSUSoplev calibration for PRM

[Manasa, Sendhil, Yuta]

We calibrated oplev for PRM. Calibration factor for C1:SUS-PRM_OL(PIT|YAW)_IN1 are;
  OLPIT: 15.6 +/- 0.3 counts/mrad
  OLYAW: 17.8 +/- 0.3 counts/mrad


We needed these values for g-factor measurement of PRC using angle dithering method.

What we did:
  1. Adjusted QPD offsets (C1:SUS-PRM_OL[1-4]_OFFSET) by zeroing the output when turned oplev laser was turned off.
  2. Centered PRM oplev beam on QPD using steering mirror.
  3. Mounted PRM oplev QPD on a xy-stage and centered the beam on QPD.
  4. Moved QPD in x and y using micrometers and measured dependance of C1:SUS-PRM_OL(PIT|YAW)_IN1 on QPD displacement.
  5. Measured the path length of PRM oplev returning beam. We get the in-vac path length using optical layout CAD. We measured out of vac path using scale and tape measure.
  6. Dismounted PRM QPD from the stage and put it back to the original position.

Result:
  1. Figures below are OLPIT/OLYAW dependance on micrometer displacement moved in x and y. Error bars are measured fluctuation in the signal.


moved in x:PRM_PIT.png       moved in y:PRM_YAW.png


  2. We fitted the result by error function to get slope at zero crossing point. We also linear-fitted the other degree of freedom to get cross coupling between x and y. Slopes we get were;

micrometer    OLPIT          OLYAW
moved in x    4.68 +/- 0.08  0.01 +/- 0.03
moved in y   -5.32 +/- 0.10  0.11 +/- 0.03    (counts/mm)


  3. Measured the path length of PRM oplev returning beam was 3340 +/- 20 mm. This gives you the calibration factors above.

Discussion:
  [Precision] According to Jamie's calculation, expected g-factor for PRC in PR2-flipped PRMI is 0.966/0.939 (elog #8068). We care about the g-factor change in ~0.01. Also, intra-cavity power dependance on mirror angle is proportional to 1/(1-g). So, we need to calibrate mirror angle in ~few 10 % of precision in order to get useful g-factor from angle dithering measurement. Measurement precision here meets this requirement.

  [x/y coupling] Measured x/y coupling was less than 2 %. We assumed gains in 4 QPD quadrants are same, and assumed QPD is mounted well in x/y axes. These assumptions are OK considering precision we need.

  [x/y difference] Calibration factors for OLPIT/OLYAW are different by ~10 %. This is not so crazy considering the incident angle on the QPD (~20 deg) and elliptic beam shape.

ELOG V3.1.3-