Yesterday, a sequence of force and gain measurement was made to determine the imbalance in the

quadrant, magnetic-levitation prototype. This was the reason why it failed to achieve a stable levitation.

The configuration is shown schematically by the figure below:

Specifically, the following measurements have been made:

(1) DC force measurement among four pairs of magnets at fixed distance with current of the coils on and off

From this measurement,  the DC force between pair of magnets is determined and is around 1.6 N at with a

separation of 1 cm. This measurement also lets us know the gain from voltage to force near the working point.

The force between pair "2" is about 13% stronger than other pairs which are nearly identical. The force by the

coil is around 0.017 N per Volt (levitation of 5 g per 3 Volt); therefore, we need around 12 volt DC compensation

of pair "2" in order to counterbalance such an imbalance.  Given the resistence of the coil equal to 26 Om, this

requires almost 500 mA DC compensation. Koji suggested that we need a high-current buffer, instead of what

has been used now.

(2) DC force measurement among four pairs of magnets (with current of the coils off) as a function of distance

From this measurement, we can determine the stiffness of the system. In this case, the stiffness or the

effective spring constant is negative, and we need to compensate it by using a feedback control. This is

one of the most important parameters for designing the feedback control. The data is still in processing.

(3) Gain measurement of the OSEM from the displacement to voltage.

This measurement is a little bit tricky due to the difficulty to determine the displacement of the flag.

After several measurements, it gave approximately 2 V/cm.

Plan for the next few days:

From the those measurements, all the parameters for the plant and sensor that need to determine the

feedback control are known. They should be plugged into the simulink model and to see whether the

old design is appropriate or not. Concerning the experimental part, we will first try to levitate the configuration

with 2 pairs of magnets, instead of 4 pairs, as the first step, which is easier to control but still interesting.

(Rana, Yuta)

Motivation:
 We wanted to see thermal effects on the PMC.

What I did yesterday:
 Changed the current of the NPRO from 2A to 0.8A and measured the power of the reflected/transmitted light from the PMC when locked.
 I also measured the power of the reflected light when PMC is not locked (It supposed to be proportional to the output power of the laser).

Result:
 Attached. Hmmmm......
 At several points of the laser current, I could'nt lock the PMC very well. The power of the reflected/transmitted light depend on the offset voltage of the PZT.
 When the laser power was weak(~<0.9A), the power of reflected/transmitted light changed periodically(~ several minutes).

It was a bit difficult to comprehend the result.
Is it good? or bad? Have you seen the thermal effect? or not?

- Put linear lines to show the visibility of the cavity.

- Calibrate the incident power and make another plot to show the visibility (%) vs the incident power (W).

Result2:
 Attached is the visibility vs incident power(assuming output of the PD is proportional to the input laser power).
 Ideally, the graph should be flat. (In another words, attached graph in the elog #3667 shoud be linear.)
 But the visibility reduces with higher laser power in this graph. This is maybe because of the thermal effect. I'm thinking about how to confirm this.

I measured openloop transfer functions of PRM/BS/ITMX/ITMY SUSPOS servo.
They look great. They all have ~50 deg phase margin and damps only POS resonance.

we set the offsets for the MCWFS DC and for the MCWFS demod outputs and then turned off the lights put the MZ at half fringe and then centered the spots on the MCWFS heads.

The MCREFL beam looks symmetric again and the MC REFL power is low. 

To fix the apparent slowness of execution of the caput commands on megatron, I changed the "ewrite" macro in the mcup and mcdown scripts to use ezcawrite instead of caput. The old lines are simply commented out, and can be reverted to at any point if we so desire. After these changes, we saw that both scripts complete execution much faster.

It looks like Tomislav's measurements of the WFS demod board noise were actually of the cable that goes from the whitening to the ADC. So the huge low frequency excess that he saw is not due to wind, but just the inverse whitening of the digital system?

In any case, today, I looked at the connections from the Whitening to the ADC. It goes through an interface chassis to go from ribbon to SCSI. The D-Sub connectors there have the common problem in many of the LIGO D-sub connectors: namely that the strain relief nuts are too tall and so the D connector doesn't seat firmly - its always about to fall out. JC, can you please take a look at this and order a set of low profile nuts so that we can rework this chassis? Its the one between the WFS whitening and the SCSI cables which go to the ADCs.

After pushing them in, I confirmed that the WFS are working, by moving all 6 DoF of the MC mirrors via bias slider, and looking at the step responses (attached). As you can see, all sensors see all mirrors, even if they are noisy.

Next up: get a breakout for the demod output connector and measure the noise there.

For today, I aligned the IMC by hand, then centred the WFS beams by unlocking the IMC and aligning the bright beam. I noticed that the WFS1 beam was being dumped randomly, so I angled the WFS1 by ~3 deg and dumped the specular reflection on a razor blade dump. To handle the sign change in the MC1 actuation (?), I changed the sign in the MC1 ASC filter banks. MCWFS loops still nto closing, but they respond to mirror alignment.

 I made several scripts to handle the mcass configuration and sensing measurements:

- The scripts and data are in the scripts/ASS directory

- The mcassUp script restores the settings for the digital lockins: oscillator gains, phases, and filters. The MC mirrors are modulated in pitch at 10, 11, 12 Hz and in yaw at 10.5, 11.5, and 12.5 Hz. The attached plot shows the comb of modulation frequencies in the MCL spectrum.

- The mcassOn and mcassOff scripts turn on and off the dither lines by ramping up and down the SUS-MC1_ASCPIT etc gains

- The senseMCdecenter script measures the response of the MCL demodulated signals to the decentering of the beam on the optics by imbalancing the coil gains by 10% which corresponds to the shift of the optic rotation point relative to the beam by 2.65 mm (75mm diameter optic) and allows calibration of the demodulated signals in mm of decentering. The order of the steps was MC1,2,3 pitch and MC1,2,3 yaw. The output of the script can be redirected to the file and analyzed in matlab. The attached plot shows the results. The plot was made using the sensemcass.m script in the same directory.

- The senseMCmirror script measures the response of the MCL demodulated signals to the mirror offsets (SUS-MC1_ASCPIT etc filter banks). The result is shown below (the sensemcass.m script makes this plot as well). There is some coupling between pitch and yaw drives so the MC coils can use some balancing - currently all gains are unity.

- The senseMCdofs scripts measures the response to the DOF excitation but I have not got to it yet.

- The next step is to invert the sensing matrix and try to center the beams on the mirrors by feeding back to optics. Note that the MC1/MC3 pitch differential and yaw common dofs are expected to have much smaller response than the other two dofs due to geometry of this tree mirror cavity. We should try to build this into the inversion.

 { Joe and Kiwamu },

 Now we  are able to compile the model file with more than 4 binary input/outputs (BIOs).

 As I wrote in a past entry (see here), the number of the BIOs was limited to 4, which is not enough for us.

  We modified a header file called "cdsHardware.h"  in order to allow model files having more than four BIOs.

The header file lives under /cvs/cds/caltech/advLigoRTS/src/include/drv/.

There was a sentence defining the maximum number in the file:

 #define MAX_DIO_MODULES         4.

We changed this to

 #define MAX_DIO_MODULES         8.

FYI, you can trick out matplotlib by creating a matplotlibrc config file. This allows you to set defaults for plot size, trace color, fonts, grids, etc., analogous to what is achieved in ATF:1840 for Matlab.

Note also that matplotlib supports LaTeX by default (if you have LaTeX installed), which means, for example, that you can include true square roots on your spectral densities:

plt.ylabel('Voltage spectral density (V/$\\sqrt{\\mathrm{Hz}}$)')

Since the backslash is used for escape characters in python, you must escape LaTeX backslashes.

For maximum effect, you can set the following lines in your matplotlibrc file:

text.usetex = True

text.latex.preamble = \usepackage{txfonts}

Then all text and mathematics in your plot will be sent through LaTeX for processing and will appear in Times.

Also, why is the conversion from watts to volts V = 50 * sqrt(W) and not V = sqrt(50 * W)?

I have wiped out the 2008a install of 64-bit linux matlab and installed 2009a in its place. Enjoy.

Yi Xie and Haixing,

We used the Gauss meter to measure the strength distribution of bought magnets, which follows a nice Gaussian distribution.
We pick out four pairs--four fixed magnets and four for the levitated plate that are matched in strength. The force difference is
anticipated to be within 0.2%, and we are going to measure the force as a function of distance to further confirm this.

In the coming week, we will measure various transfer functions in the path from the sensors to the coils (the actuator). The obtained
parameters will be put into our model to determine the control scheme. The model is currently written in mathematica which can
analyze the stability from open-loop transfer function.

I checked out a copy of matapps into /cvs/cds/caltech/apps/lscsoft so that I could find the matlab function strassign.m, which is necessary for some old mDV commands to run.  I don't know why it became necessary or why it disappeared if it did.

 I changed the Martian wireless router to use channel 10 instead of something random (as it was). Using the Android app 'Wifi Analyzer' we could see that the usual channels are dominated by FlumeLab and Caltech Beaver.

The range from 9-13 looked clean so we put it up there. Also, the signal strength drops from -45 to -70 dBm as we walk from the BS down to the ends. We need to tweak the router position and orientation to give us another 10 dB so that we can reliably run the laptops at the ends.

Background:
 We need laptops that connect to the wireless network to use them in the lab.

mariabella:
 Dell Inspiron 1210 laptop
 Broadcom Corporation BCM4312 802.11b/g (rev 01) (PCIID: 14e4:4315 (rev 01))

What I did:
1. I followed the same steps I did for aldabella: http://nodus.ligo.caltech.edu:8080/40m/3623
 Except I unzipped R151517-pruned.zip.
   http://myspamb8.googlepages.com/R151517-pruned.zip

2. Note that the PCIID is important for driver selection. Not the model No.
 To check whether your driver selection is correct, run:
  # ndiswrapper -l
 after installing the driver.
 If the driver selection is wrong, it will return only:
  bcmwl5 : driver installed
 If correct, it will return:
  bcmwl5 : driver installed
         device (14E4:4315) present (alternate driver: hoge)
 This page has some information for the driver selection:
   https://help.ubuntu.com/community/WifiDocs/Driver/bcm43xx/Feisty_No-Fluff#Step%202:%20Download%20and%20Extract%20Drivers

Result:
 aldabella now connects to the wireless martian network.

Note:
 Broadcom official driver didn't work for mariabella, too.

So, it appears that one doesn't even have to change the Marconi set frequency to alter the phase of the output signal.  It appears that other front panel actions (turning external modulations on/off, changing the modulation type) can do it as well.  At least that's what I conclude from earlier this morning, when after setting up the f2 Marconi (166MHz) for external AM, the double-demod handoff in the DRMI no longer worked.  Luckily this isn't a real problem now that we have the setDDphases and senseDRM scripts. 

 The real problem is that we are using frequency synthesizers to make the beat signals (133 and 199) instead of mixers. Luckily, the future 40m will not use beat signals (?) or synthesizers.

The horizontal trolley drive stopped working  at the east end this morning. It is working intermittently. In the worst case we can take the door off with the manual -Genie- lift.

I'm working with Konecrane to solve  the wormgear drive problem.

 Gear box found, it's  lead time one week at $825    The crane may be functional round August 25

• copied over /etc/fstab lines from pianosa sothat the NFS mounts work correctly
• added symlinks so that the NFS dirs mount in the right dirs
• installed Opera browser
• symlink libsasl2.so.3 -> libsasl2.so.2 and now DTT runs and can get data now and in the past
• DTT can natively produce PDF so you don't have to take screen caps of your camera phone and make a chalk drawing of that anymore
• sitemap/MEDM is working
• after editing fonts.alias as detailed in Thorne wiki, I ran 'sudo xset fp rehash' to get MEDM to notice new fonts. MEDM Scalable fonts are back!!
• installed Grace and now dataviewer works
• ndscope not running: yum install ndscope breaks because it can't find a couple of python34 packages
• tested that AWGGUI also runs and puts in real sine waves

cdsutils is not working on rossa.

Import cdsutils produces this error:

In [2]: import cdsutils
---------------------------------------------------------------------------
OSError                                   Traceback (most recent call last)
<ipython-input-2-949babce8459> in <module>()
----> 1 import cdsutils

/ligo/apps/linux-x86_64/cdsutils-480/lib/python2.7/site-packages/cdsutils/__init__.py in <module>()
     53 
     54 try:
---> 55     import awg
     56 except ImportError:
     57     pass

/ligo/apps/linux-x86_64/cdsutils-480/lib/python2.7/site-packages/cdsutils/awg.py in <module>()
     30 """
     31 
---> 32 import sys, numpy, awgbase
     33 from time import sleep
     34 from threading import Thread, Event, Lock

/ligo/apps/linux-x86_64/cdsutils-480/lib/python2.7/site-packages/cdsutils/awgbase.py in <module>()
     17 libawg = CDLL('libawg.so')
     18 libtestpoint = CDLL('libtestpoint.so')
---> 19 libSIStr = CDLL('libSIStr.so')
     20 
     21 ####

/ligo/apps/anaconda/lib/python2.7/ctypes/__init__.pyc in __init__(self, name, mode, handle, use_errno, use_last_error)
    364 
    365         if handle is None:
--> 366             self._handle = _dlopen(self._name, mode)
    367         else:
    368             self._handle = handle

OSError: libSIStr.so: cannot open shared object file: No such file or directory

(Joe, Yuta)

 In elog #3708, we showed how to edit all the similar medm screens easiliy.
 But if there are no master files you want to edit in /opt/rtcds/caltech/c1/medm/master/ directory, you can make one.
 Say, you want to edit all the similar medm screens named C1SUS_NAME_XXX.adl.

1. Copy one of C1SUS_NAME_XXX.adl to /opt/rtcds/caltech/c1/medm/master/ directory as C1SUS_DEFAULTNAME_XXX.adl.

2. Go to that directory and
  sed -i 's/NAME/DEFAULTNAME/g' C1SUS_DEFUALTNAME_XXX.adl

3. Add "_XXX.adl" to file_array list in generate_master_screens.py

4. Edit C1SUS_DEFUALTNAME_XXX.adl

5. Run ./generate_master_screens.py

That's all!!

Previously, for some reason, many IPC connections were routed through the c1rfm model, even if a direct IPC connection was possible.  It's unclear why this was done.  I spoke to Joe B. about it and he couldn't remember either.  Best guess is that it was just for book keeping purposes.  Or maybe some old timing issue that has been fixed by DMA fixes in the RTS.  So the point is that it's no longer needed, and we can reduce delays by making direct connections.

I made direct IPC connections from c1lsc to both c1sus and c1mcs, bypassing the c1rfm, through which they had previously been routed.  All models were rebuilt/installed/restarted and everything seems to be working fine.

We ripped out all of the old AS, PLL, and REFL paths, green, orange, and cyan respectively on the old AP table layout photo:

• AS (green): had already been re-purposed by putting a ThorLabs diode right after the first steering mirror.   Everything downstream of that has been removed.
• PLL (orange): everything removed.
• REFL (cyan): CCD was left in place, so everything upstream of that was not touched.  Everything else was removed, including all of the REFL detectors.
• OMCT (purple): previously removed
• OMCR (blue): left in place, but the diode and CCD are not connected (found that way).
• MCT (magenta): previously removed.
• IMRC (red): untouched

All optics and components were moved to the very south end of the SP table.

We also removed all spurious cables from the table top, and from underneath, as well as pulled out no-longer-needed power supplies.

Innolight 2W 1064nm main laser was turned off for more enclosure related work.

The electrician re rooting the power- conduit to the interlock under the floor and bring it through the new concrete tunnel.

Emergency laser power shut off switch was tested at entry door 104M.  It worked fine.

No laser glasses required. Laser will be turned back on around 11 am today.

The main laser went off when PSL doors were opened-closed. It was turned back on and the PSL is locked.

Atm1,   AC power line to enclosure and interlock  was extended.

Atm2,   24V line to interlock rerouted

Atm3,   job is completed

SAFETY GLASSES REQUIRED !  SAFETY GLASSES REQUIRED!

 The laser is turned on. Injection current set to 0.871A.

Actually some one turned the  laser  off last night and did  not enter it into the elog ! Burned toast award is granted !

Please  come forward voluntarily.

I turned off the laser last night to protect against the electricians. but failed to elog it. I accept the burnt toast completely.

I have created a directory under the svn. The link is https://nodus.ligo.caltech.edu:30889/svn/trunk/docs/haixing

In the directory, there are three folders are related to the magnetic levitation.

The experimental data is in the "experiment_data".

The comsol numerical modelling files are in "mag_levi_comsol_modelling" which contains "1x1 magnets",

"4x4 magnets" and "16x16 magnets" sub-folders where detailed modelling results are included.The mathematica

notebooks in those folders are used to produce the plots I posted on the wiki page.

The "mag_levi_feedback" contains the Simulink modelling of the feedback loop. To generate the plot for the

open-loop transfer function. One needs to ruc the "mag_lev.m" file.

 Joe and Steve

The Maglev is running at 680 Hz, 40,800 RPM with V1 gate valve  closed and  valve disabled to change position. C1vac2 was rebooted before starting.

Interlocks are not tested yet, but the medm COVAC_MONITOR.adl screen is reading correctly. RGA scan will determine the need for baking on Monday

The foreline pressure is still  ~2e-5 Torr

Acceleration takes 3 minutes 30sesconds without load. There is no observabale temp effect on the body of the turbo during braking and acceleration.

The IFO is still pumped by the CRYO only

Our Osaka TG360MB maglev failed with CSB error message. This means that the dry emergency landing bearing has to be replaced.

I will consalt with Osaka about the choice of replacing bearing or installing new spare  tomorrow.

Mean while V1 is closed and the vac envelope is not pumped.

Valve configuration: BG -background, pumping on the RGA-only

High voltage to IOO PZT steering mirrors and OMC are turned off.

PSL output shutter is closed and manual block is in place.

I will start cooling the CYO pump in the morning, so the IFO will be pumped by noon.

Outgassing plus leakrate after  10 hrs the pressure is 2.3 mTorr

This rate of rise is normal and it is safe to work with the ifo.

The connection between our coil wires and BNC terminals was pretty awful (soldered wires broke off ) so we removed the old heat shrink and re-soldered the wires.  We then chose more appropriately sized heat shrinks (small one around each of the two soldered wires, a medium-sized shrink around the wires together, a large one covering the BNC terminal and the wire) and used the solder iron and heat gun to shrink them.

2009 May 18 03:39:36 UTC

Earthquake Details

We laid the cable along the cable keeper from the BACARDI seismometer to the rack 1X6, the excess cable has been coiled under the X arm.

We plugged the cable to the seismometer and to the seismometer electronics box in rack 1X6. We also plugged the AC power cable from the box to an outlet in rack 1X7 (because the 1X6 outlets are full)

With the help of a function generator we tested the following labeled channels of AA board...

2, 3, 11, 12, 14, 15, 16, 18, 19, 20 and 24

that are the channels that can be viewed by the dataviewer, also the channel 10 can be viewed but it's labeld BAD so we cannot use it.

We leveled the seismometer and unlocked it, and saw his X,Y,Z velocity signals with an oscilloscope.

 Just to be clear what I said at the meeting, I write all this down here. Adaptive filtering of real signals (MC_F and GUR1_X) with all noises inside is 

This is offline filtering but with real signals and with the C-code that is compiled at the 40m now. We can reduce the MC_F signal by ~100 below 10 Hz, but  the problem is that reducing the adaptation gain, the error increases. As a result when we move towards FxLMS algorithm with AA, AI and downsampling, we have to take the gain equal to ~1e-2 and we do not reduce any noise. 

The second demonstration of this problem is static Wiener filtering. This is the result

We can see that adaptive filtering outperforms the "optimal" filtering. This is because an adaptive filter can follow the changes of coefficients immediately while the Wiener filter averages them. This is the mathematical formulation:

mcl_real = coeff _real* seismic_noise_real + other_noise

mcl_real - the real length of the MC,

coeff_real - real coefficients, that represent the transfer function between seismic noise and MC length,

other_noise - noise uncorrelated to the seismic noise seismic_noise_real

But in the world of our measured signals we have the equation

mcl_measured = coeff * seismic_noise_measured + other_noise

mcl_measured = TF_mcl * mcl_real

seismic_noise_measured = TF_seis * seismic_noise_real

where TF_mcl and TF_seis - transfer functions from the real world to measurements.

It seems to me that TF_mcl or TF_seis are not constants and for that reason the TF between measured seismic noise and mcl is not constant. But it is exactly what an adaptive or Wiener filter tries to define:

coeff(time) = average(coeff(time)) + delta(coeff(time))

The result of applying average(coeff) is the green line in the Figure 2 - error after applying the Wiener filtering.

delta(coeff) - the changing part of the transfer function is caught by the adaptive filtering. The lower the gain, the lower is the capability of adaptive filter to catch these changes. Theoretically. the error after applying adaptive filter can be presented like this:

E(error*error) = E(other_noises*other_noises) + 1/(2-mu)*mu*E(other_noises*other_noises)  + 1/ {mu*(2-mu)} * Tr(Q) * A

where mu = adaptation gain

Q - covariance matrix of delta(coeff)

A - norm of the seismic signal

The first term in this equation is the dispersion of other noises, the second term is the error of the adaptive filter due to non-zero gain, the third term is due to the changes in the transfer function - we can see that it is proportional to 1/mu. This term explains why the error increases while mu decreases.

Now I'm looking for the part in the path of the signals where the transfer function can change. As I mentioned above, this is not a change in the real world, it is the change in the measured signlals. My first guess is the quantization error - we do not have not enough counts. If this is not the case, I'll move to other things of the signal path.

I got around to actually try building the LSC and IFO models on megatron.  Turns out "ifo" can't be used as a model name and breaks when trying to build it.  Has something to do with the find and replace routines I have a feeling (ifo is used for the C1, H1, etc type replacements throughout the code).  If you change the model name to something like ifa, it builds fine though.  This does mean we need a new name for the ifo model.

Also learned the model likes to have the cdsIPCx memory locations terminated on the inputs if its being used in a input role (I.e. its bringing the channel into the model).  However when the same part is being used in an output role (i.e. its transmitting from the model to some other model), if you terminate the output side, it gives errors when you try to make.

Its using the C1.ipc file (in /cvs/cds/caltech/chans/ipc/) just fine.  If you have missing memory locations in the C1.ipc file (i.e. you forgot to define something) it gives a readable error message at compile time, which is good.  The file seems to be being parsed properly, so the era of writing "0x20fc" for block names is officially over.

 I suggest "ITF" for the model name.

We're trying to do a yarm measurement....before I forget, I want to write this down...

I changed the gain of each of the top 2 SR560's down, by a factor of 2.  This made the overload lights quit coming on.

PSL output is stable.

This morning valve condition: V1, VM1, V4 and V5 valves were closed. IFO pressure rose to 1.3 mTorr

It was caused by low N2 pressure.  Our vacuum valves are moved-controlled by 60-70 PSI of nitrogen.

When this supply drops below 50-60 PSI the interlock closes V1 valve. This is the minimum pressure required to move the large valves.

It is our responsibility to check the N2 cylinder pressure supply.

The vacuum valve configuration is back to VAC. NORMAL,  CC1  4.8E-6 Torr

PS: Bob says that the second cylinder was full this morning, but the auto-switch over did not happen.

Last time we designed MCL loop with UGF ~ 30 Hz and I think, it was hard to lock the arm because of large frequency noise injected to IFO.

This time I made a low bandwidth MCL loop with UGF=8 Hz. MCL error RMS is suppressed by factor of 10 and arms lock fine.

Attached plots show MCL OL, MCL error suppression and frequency noise injection to arms.

It is interesting that spectrum of arms increases below 1 Hz meaning that IMC sensing noise dominates in this range.

I did not include the loop into the IMC autolocker. I think it is necessary to turn it on only during day time activity and when beatnote is moving too much during arm stabilization.