Koji, Joe, and I are planning to try controlling the ETMY, on Monday or Tuesday.  Our plan is to try to do this with megatron out of the RFM loop.   The RCG system includes pos, pit, yaw, side, and oplevs.  I will use matrix elements as currently assigned (i.e. not the ideal case of +1 and -1 everywhere).   I will also match channel names to the old channels.   We could put buttons on the medm screen to control the analog DW by hand.  

Something strange was going on in the OAF code, printf would print a double precision number in %f format but not in %lf or %e format!

Since we know this problem now, we can move forward, but it will be important to know why printf was restricted and if there are other such constraints which we should remember while making changes in the codes.

elog was acting up again (not running), so I restarted it. 

And again.  This makes 4 times since lunchtime yesterday....something bad is up.

I am using SR785 Spectrum Analyzer now and also tomorrow. 
I will put it back on Sunday. If anyone needs it during the weekend,
please just take it and I can reset it by myself later. Thanks.

I measured the open-loop transfer function of the magnetic levitation system.

The schematic block diagram for this measurement is the following:

I injected a signal at a level of 20mV between two preamplifiers, and the corresponding open-loop

transfer function is given by B/A.  I took a picture of the resulting measurement, because

I encountered some difficulties to save the data to the computer via the wireless network.

The bode plots for the transfer function shown on the screen is the following:

I am puzzled with the zero near 10 Hz. I think it should come from the mechanical response function, because there is no zero in the transfer functions

of the preamplifer and the coil itself. I am not sure at the moment.

The corresponding configuration of the levitated magnet is

This afternoon I re-enabled the ETMY coils after I found that the watchdogs for the mirror had tripped last night at 2:06am.

Tonight I aligned the IFO by running the scripts one by one.

SRC was far off and I had to align SRM by hand before the script could work. SPOB is still low when DRM is aligned.

I'm restoring the full IFO now that I'm taking off.

I used the coh_carpet.m function from the mDV to calculate this plot:

coh_carpet('C1:PEM-ACC_MC1_X','C1:PEM-ACC_MC2_X',gps('now - 3 days'),3600*12,4,10,64)

It shows the coherence v. time of two of our X-direction accelerometers starting around 1AM on Friday and going for 12 hours.

I'm not sure what it means exactly, but it looks like the coherence is relatively steady as a function of time. I will need more RAM than Rosalba or a smarter code to calculate longer time stretches.

MC2 damping restored,  MZ locked and the arms are flashing now.

I'm working on the PSL table to set up the PLL setup for the AbsL experiment.

Alex and I took a look at megatron this morning, and it was in the same state I left it on Friday, with file system errors.  We were able to copy the advLIGO directory Peter had been working in to Linux1, so it should be simple to restore the code.  We then tried just running fsck, and overwritting bad sectors, but after about 5 minutes it was clear it could potentially take a long time (5-10 seconds per unreadable block, with an unknown number of blocks, possibly tens or millions).  The decision was made to simply replace the hard drive.

Alex is of the opinion that the hard drive failure was a coincidence.  Or rather, he can't see how the RFM card could have caused this kind of failure.

Alex went to Bridge to grab a usb to sata adapter for a new hard drive, and was going to copy a duplicate install of the OS onto it, and we'll try replacing the current hard drive with it.

Apparently the random file system failure on megatron was unrelated to the RFM card (or at least unrelated to the physical card itself, its possible I did something while installing it, however unlikely).

We installed a new hard drive, with a duplicate copy of RTL and assorted code stolen from another computer.  We still need to get the host name and a variety of little details straightened out, but it boots and can talk to the internet.  For the moment though, megatron thinks its name is scipe11.

You still use ssh megatron.martian to log in though.

We installed the RFM card again, and saw the exact same error as before.  "NMI EVENT!" and "System halted due to fatal NMI".

Alex has hypothesized that the interface card the actual RFM card plugs into, and which provides the PCI-X connection might be the wrong type, so he has gone back to Wilson house to look for a new interface card.  If that doesn't work out, we'll need to acquire a new RFM card at some point

After removing the RFM card, megatron booted up fine, and had no file system errors.  So the previous failure was in fact coincidence.

I removed the beam splitter and the PDA 255.

the beam path to the RFAM photodiode is clear again.

 Drill press is all better now.  A spare switch is in the top drawer with the drill bits.

It won't start--it just sits at Waiting for EPICS BURT, even though the EPICS is running and BURTed.

[controls@c1omc c1omc]$ sudo ./omcfe.rtl
cpu clock 2388127
Initializing PCI Modules
3 PCI cards found
***************************************************************************
1 ADC cards found
        ADC 0 is a GSC_16AI64SSA module
                Channels = 64
                Firmware Rev = 3

***************************************************************************
1 DAC cards found
        DAC 0 is a GSC_16AO16 module
                Channels = 16
                Filters = None
                Output Type = Differential
                Firmware Rev = 1

***************************************************************************
0 DIO cards found
***************************************************************************
1 RFM cards found
        RFM 160 is a VMIC_5565 module with Node ID 130
***************************************************************************
Initializing space for daqLib buffers
Initializing Network
Waiting for EPICS BURT




From looking at the recorded data, it looks like the c1omc started going funny on the afternoon of Nov 5th, perhaps as a side-effect of the Megatron hijinks last week.

It works when megatron is shutdown.

To estimate the noise floor of the Ranger, Rana and I locked the mass on the seismometer, so there will be no (aka minimal) signal from the motion of the ground in the pickup coil.  We should be seeing primarily the noise of the readout electronics.  We also put the Ranger on top of one of the foam lids from the Seismometer Isolation Boxes to further isolate from ground motion (this didn't change the signal noticeably).  

In this plot, Green is the locked-mass-on-foam noise floor, blue is the regular spectra, with the SR560 AC coupled, and the red is the regular seismic spectra with the SR560 DC coupled.  There doesn't seem to be a noticeable difference between blue and red (the spectra were taken at different times of day, with the red taken at night, when we generally expect things to be quieter).  I'm leaving the SR560 DC coupled.  (Rana had found it earlier this afternoon GND coupled....not sure yet why).

Also, we're not sure that the green curve is true readout noise, vs. how much of it is specifically due to the fact that the mass is locked down.  Especially around a few hundred Hz, the green curve is much higher than the other 2, and at a few tens of Hz there is some weird peak action.  However, this will be okay as a first-run noise estimate for the Ranger's noise floor.

The question at hand is: Do we need to redo any of the Ranger's readout electronics (i.e. replace the SR560 with a Pomona Box circuit) to lower the noise floor, or is it okay as-is?

We found that someone had set the name of megatron to scipe11. This is the same name as the existing c1aux in the op440m /etc/hosts file.

We did a /sbin/shutdown on megatron and the OMC now boots.

Please: check to see that things are working right after playing with megatron or else this will sabotage the DR locking and diagnostics.

Last night around 5pm or so, Alex had remotely logged in and made some fixes to megatron.

First, he changed the local name from scipe11 to megatron.  There were no changes to the network, this was a purely local change.  The name server running on Linux1 is what provides the name to IP conversions.  Scipe11 and Megatron both resolve to distinct IPs. Given c1auxex wasn't reported to have any problems (and I didn't see any problems with it yesterday), this was not a source of conflict.  Its possible that Megatron could get confused while in that state, but it would not have affected anything outside its box.

Just to be extra secure, I've switched megatron's personal router over from a DMZ setup to only forwarding port 22.  I have also disabled the dhcp server on the gateway router (131.215.113.2).

Second, he turned the mdp and mdc codes on.  This should not have conflicted with c1omc.

This morning I came in and turned megatron back on around 9:30 and began trying to replicate the problems from last night between c1omc and megatron.  I called Alex and we rebooted c1omc while megatron was on, but not running any code, and without any changes to the setup (routers, etc).  We were able to burt restore.  Then we turned the mdp, mdc and framebuilder codes on, and again rebooted c1omc, which appeared to burt restore as well (I restored from 3 am this morning, which looks reasonable to me). 

Finally, I made the changes mentioned above to the router setups in the hope that this will prevent future problems but without being able to replicate the issue I'm not sure.

From fitting the arm cavity transfer functions I got the following values for the cavity pole frequencies.

X ARM: fp_x = (1720 +/- 70) Hz

Y ARM: fp_y = (1650 +/- 70) Hz

Attached are the plots from the fitting.

Aligning the beam for the PLL of the AbsL Experiement I rotated the polarizer along the path of the MC Input pick off beam (= the pick off coming from the MC periscope).

I've been trying to lock the PLL for the AbsL Experiment but I can't see the beat (between the auxiliary NPRO and the PSL).

I believe the alignment of the PLL is not good. The Farady Isolator is definitely not perfectly aligned (you can see it from the beam spot after it) but still it should be enough to see something at the PLL PD.

it's probably just that the two beams don't overlap well enough on the photodiode. I'll work on that later on.

I'm leaving the lab now. I left the auxiliary NPRO on but I closed its shutter.

All the flipping mirrors are down.

Mostly a note to self:  I have put terminators on the ADC inputs which are usually the PEM-SEIS-GUR2_(XYZ) channels.  Since these 3 signals are currently going into the ASS ADC, these PEM ADC inputs are open, and have predefined channel names.  I'll collect the data and put it as the ADC noise level in my nifty plot which will show the noise limits of all things which affect Wiener Filtering.

 I've added the side coil to the model controller and plant, and the oplev quad to the model controller and plant.  After the megatron wipe, the code now lives in /home/controls/cds/advLigo/src/epics/simLink.  The files are mdc.mdl (controller) and mdp.mdl (plant).  These RCG modules go at 16K with no decimation (no_oversampling=1 in the cdsParameters block) so hopefully will work with the old (16K) timing.

I've loaded many of the filters, there are some eft to do.  These filters are simply copied from the current frontend.  

Next I will port to the SUS module (which talks to the IO chassis).  This means channel names will match with the current system, which will be important when we plug in the RFM.

RFAMPD_DCMON disappered on Nov 5, 2009

The attached plot shows the spectra of the 3 Z axes of the 3 seismometers we have (this data is from ~20Aug2009, when the Ranger was in the Z orientation) in Magenta, Cyan and Green, and the noise of each of the sensors in Red, Blue and Black.  The noise curves were extracted from the spectra using the Huddle Test / 3 Corner Hat method.  The Blue and Black traces which are just a few points are estimates of the noise from other spectra.  The Blue points come from the Guralp Spec Sheet, and the Black comes from the noise test that Rana and I did the other day with the Ranger (elog 2223).  

I'm not really happy with the black spectra - it looks way too high.  I'm still investigating to see if this is a problem with my calibration/method....

I've opened the AP table and I'm working on it.

I re-aligned the Faraday on the AP table. I also aligned the beam to the periscope on the PSL and all the other optics along the beam path.  Now I have a nice NPRO beam at the PLL which overlaps with the PSL beam. The alignment has to be further improved because I see no beat yet.

I wonder if the all the tinkering on the PSL laser done recently to revive the power has changed the PSL NPRO temperature and so its frequency. That could also explain why the beat doesn't show up at the same temperature of the NPRO as I used to operate it. Although I scanned the NPRO temperature +/- 2 deg and didn't see the beat. So maybe the misalignment is the casue.

Not feeling very well right now. I need to go home for a while.

AP table closed at the moment.

NPRO shutter closed

 We definitely changed the PSL NPRO temp while fiddling around, trying to increase the laser power.  I think it's noted in the elog both times that it's happened in the last few months (once when Rana, Koji and I worked on it, and then again when it was just Koji), but we opened up the side of the MOPA box so that we could get at (and change) the potentiometer which adjusts the NPRO temp.  So you may have to search around for a while.

Yes it did.

For long time, the crystal temperature C1:PSL-126MOPA_LTMP was 43~46deg. Now it is 34deg. Try ~10deg lower temperature.

The .mdl code for the mdc and mdp development modules is finished.  These modules need more filters, and testing.  Probably the most interesting piece left to do is putting in the gains and filters for the oplev model in mdp.  It might be OK to simply ignore oplevs and first test damping of the real optic without them.   However, it shouldn't be hard to get decent numbers for oplevs, add them to the mdp (plant) module, and make sure the mdc/mdp pair is stable.  In mdp, the oplev path starts with the SUSPIT and SUSYAW signals. Kakeru recently completed calibration of the oplevs from oplev cts to radians:   1403  .  From this work we should find the conversion factors from PIT and YAW to oplev counts, without making any new measurements.  (The measurements wouldn't be hard either, if we can't simply pull numbers from a document.)  These factors can be added to mdp as appropriate gains.

I've also copied mdc to a new module, which I've named "sas" to address fears of channel name collisions in the short term, and replaced the cpu-to-cpu connections with ADC and DAC connections.  sas can be the guy for the phase I ETMY test.  When we're happy with mdc/mdp, we hopefully can take the mdc filter file from chans, replace all the "MDC" strings with "SAS", and use it.

I have been working about multi-resonant EOM since last week.

In order to characterize the behavior of the each components, I have made a simple LC tank circuit.

You can see the picture of the circuit below.

Before constructing the circuit, I made an "ideal" calculation of the transfer function without any assumptions by my hand and pen.

Most difficult part in the calculation is the dealing with a transformer analytically. Eventually I found how to deal with it in the analytical calculation.

The comparison of the calculated and measured transfer function is attached.

 It shows the resonant frequency of ~50MHz as I expected. Those are nicely matched below 50MHz !!

For the next step, I will make the model of the circuit with stray capacitors, lead inductors, ... by changing the inductance or something. 

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.

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.

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.

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

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.

The concrete  floor cutting has begun next door at CES

This morning I found a frequency generator connected to something on the PSL table sitting on the blue step next to the sliding doors.

Is anyone using it? Has it been forgotten there? If that's the case, can the interested person please take care of removing it?

I've opened the AP table and I'm working on it.

Also auxiliary NPRO turned on and mechanical shutter opened.

Last night there was an activity for a calibratuon work, which I helped. I can take care of the FG.

 Beat found at 30MHz with auxiliary NPRO temperature of 37.19 degrees, vs. ~48 deg as it used to be.

The beat is small (-70dBm). PLL alignment has to be improved.

I added the StochMon calibrated channels to the data trend by including the following channel names in the C0EDCU.ini file:

[C1:IOO-RFAMPD_33MHZ_CAL]
[C1:IOO-RFAMPD_133MHZ_CAL]
[C1:IOO-RFAMPD_166MHZ_CAL]
[C1:IOO-RFAMPD_199MHZ_CAL]

Before saving the changes I committed C0EDCU.ini to the svn.

Then I restarted the frame builder so now the new channels can be monitored and trended.

We connected megatron to the IO chassis which in turn was plugged into the rest of the ITMY setup.  We had manually turned the watchdogs off before we touched anything, to ensure we didn't accidently drive the optic.  The connections seem to go smoothly.

However, on reboot of megatron with the IO chassis powered up, we were unable to actually start the code.  (The subsystem has been renamed from SAS to TST, short for test).  While starttst claimed to start the IOC Server, we couldn't find the process running, nor did the medm screens associated with it work.

As a sanity test, we tried running mdp, Peter's plant model, but even that didn't actually run.  Although it also gave an odd error we hadn't seen before:

"epicsThreadOnceOsd epicsMutexLock failed."

Running startmdp a second time didn't give the error message, but still no running code.  The mdp medm screens remained white.

We turned the IO chassis off and rebooted megatron, but we're still having the same problem.

Things to try tomorrow:

1) Try disconnecting megatron completely from the IO chassis and get it to a state identical to that of last night, when the mdp and mdc did run.

2) Confirm the .mdl files are still valid, and try rebuilding them

On Rana's suggestion I checked the MC transmission QPD (C1:IOO-MC_TRANS_SUM). I found that the readout is almost zero when the MC is unlocked.

I unlocked the Mode Cleaner turning off the LSC control and disabling the autolocker. The QPD reads 0.014. It seems that there is no offset.

I also checked with the IR card around the photodetector and I didn't see any stray beam.

 PLL alignment improved. Beat amplitude = -10dBm. Good enough.

DC readouts at the PLL photodiode:

V_NPRO = -4.44V

V_PSL = -3.76V

The NPRO beam is attenuated by a N.D.=1 attenuator just before going to the photodiode.

Something strange happened at the last. Right before -10dBm, the amplitude of the beat was about -33dBm. Then I was checking the two interfering beams with the IR card and saw that they overlapped quite well. I then turned my head back to the spectrum analyzer and suddenly the beat was at -10dBm. Not only, but a bunch of new peaks had appeared on the spectrum. Either I inadvertently hit the PD moving it to a better position or something else happened.

Like if someone was making some other modulation on the beam or the modulation depth of the PSL's sidebands had gone up.

OK. I have been keeping my eyes on the MC transmission. In deed, the MC trans has been well kept at around 7.7 since the last PSL work.
Even it was over the 8 today!

PC_DRIVE is also improving after the last PSL work!

I locked the PLL and made some first measuremtns of the spectrum of the error signal. I'll post them later.

I closed the shutter of the NPRO.

I have measured the impedance of the LC tank circuit which I referred on my last entry.

The configuration of the circuit is exactly the same as that time.

In order to observe the impedance, by using Koji's technique I injected a RF signal into the output of the resonant circuit.

In addition I left the input opened, therefore the measured impedance does not include the effect of the transformer.

- - - - - - - - - - - - results

The measured impedance is attached below; "LCtank_impedance.png"

The peak around 50MHz is the main resonance and it has impedance of ~1500 [Ohm], which should go to infinity in the ideal case (no losses).

In fact the impedance looked from the input of the circuit gets reduced by 1/n^2, where "n" is the turn ratio of the transformer.

By putting the n=4, the input impedance of the circuit should be 93 [Ohm]. This is a moderate value we can easily perform impedance-matching by some technique.

I also fitted the data with a standard model of equivalent circuit (see attachment 2).

In the figure.2 red component and red letter represents the design. All the other black stuff are parasites.

But right now I have no idea the fitted value is reasonable or not.

For the next I should check the input impedance again by the direct way; putting the signal into the input.

I measured the input impedance of the LC tank circuit with the transformer. The result is attached.

It looks interesting because the input impedance is almost dominated

by the primary coil of the transformer with inductance of 75nH (see attachment 1).

The impedance at the resonance is ~100 [Ohm], I think this number is quite reasonable because I expected that as 93 [Ohm]

Note that the input impedance can be derived as follower;

(input impedance) = L1 + Z/n^2.

Where L1 is the inductance of the primary coil, Z is the load in the secondary loop and n is the turn ratio.

I think now I am getting ready to enter the next phase \(^o^)/