For a certain investigation of the sum/diff module for MCT QPD/MC REFL QPD, I removed it from the system.

The Rai box ran out of batteries a couple of days ago and so the data is no good. I've put the Ranger back on the SR560 for now (but with the damping resistor removed, so the gain is 2x more than before).

The validation for high impedance measurement has been well done.

The impedance measurement is one of the keys for designing the EOM circuit.

So far I was very struggling to measure the high impedance ( above several 1000 Ohm) at RF because the EOM circuit has a high impedance at its resonance.

Finally I realized that the measured impedance was suppressed by a parasitic resistance, which especially reduces the impedance at the resonance.

Also I found that we can extract the TRUE impedance data by subtracting the effect of the parasitic resistance from resultant data.

In order to confirm whether this subtraction works correctly or not,  the impedance was directly re-measured with another analyzer for crosscheck.

(measurement )

The measurement has been performed with help from Peter and Frank. ( Thank you !)

By using  network analyzer AG4395A with the impedance test kit AG43961A (these are at the PSL lab.), the impedance of resonant circuit with EOM was measured.

The picture of setup is attached. This impedance test kit allows to measure typically 0.1 [Ohm]-1M [Ohm] and frequency range of 100kHz-500MHz.

(result)
The resultant plot is attached. In the plot the blue curve represents the impedance measured by usual analyzer at 40m.

Note this curve is already subtracted the effect of the parasitic resistance.

( the parasitic resistance is in parallel to the circuit and it has ~7.8k Ohm, which is measured while the probe of the analyzer stays open. )

The red curve is the re-measured data using the impedance test kit.

The important point is that; these two peak values at the resonance around 40MHz show good agreement in 10%.

The resonant frequencies for two data differs a little bit, which might be the effect of a stray capacitance ( ~several [pF] )

The red curve has a structure around 80MHz, I think this comes from the non-coaxial cables, which connect the circuit and analyzing kit.

You can see these cables colored black and red in the picture.

( conclusion )

Our measurement with the subtraction of the  parasitic resistance effect is working reliably !

I found that MCT QPD has a dependence of the total output on the position of the spot. Since the QPD needs the supply and bias voltages from the sum/diff amp, I could not separate the problems of the QPD itself and the sum/diff amplifier by the investigation on Tuesday. On Wednesday, I investigated a generic quad photodiode interface module D990692.

...I was so disappointed. This circuit was left uninvestigated and used so long time with the following sorrowful conditions.
- This circuit has 4 unbuffered inputs with input impedance of 300~400 Ohm. It's way too low!
- Moreover, those channels have different input impedances. Ahhhh.
- Even worse, the QPD circuit D990272 has output impedance of 50 Ohm.
- The PCB of this circuit has four layers. It is quite difficult to make modifications of the signal route.
- It is a headache: this circuit is "generic" and used in many places.

D990692 has 4 channel inputs that are not buffered. Each channel has two high impedance buffers but they are used only for the monitors. The signal paths have no buffer.

The differential amplifier is formed by R=1k Ohm. The inverted side of the input has 1kOhm impedance. The non-inverted side has 1.5kOhm impedance.

CH1: 10K // 1.5k // 1.5k // 1k = 411 Ohm
CH2: 10K // 1.5k // 1k // 1k = 361 Ohm
CH3: 10K // 1k // 1k // 1k = 323 Ohm
CH4: 10K // 1k // 1.5k // 1k = 361 Ohm

Considering the output impedance of 50Ohm for the QPD, those too low input impedances result in the following effect:
- Because of the voltage division, we suffer absolute errors of 10.8~13.4%. This is huge.
- Because of the input impedance differences, we suffer a relative error of 1.5%~3%. This is also huge.

Unfortunately, the circuit has no room to modify; the signal paths are embedded in the internal layer.

I decided to replace the resistors of the sum/diff amps from 1k to 10k. Also the input impedance of the buffer was removed as the input is terminated by the sum/diff amps in any case.This changes the input inpedance to the followings:

CH1: 15k // 15k // 10k = 4286 Ohm
CH2: 15k // 10k // 10k = 3750 Ohm
CH3: 10k // 10k // 10k = 3333 Ohm
CH4: 10K // 15k // 10k = 3750 Ohm

These yield the absolute error of 1.2-1.5%. The relative error is now 0.3%. I can accept these numbers, but later I should put additional terminating resistors to compensate the differencies.

So far I have modified the resistors for the MCT as the modification for a QPD needs 17 10k resistors.
Next thing I have to check is the dependence of the QPD outputs on the spot positions.

-----------------------------------------------

Edit: Feb 11, 2010

I talked with Frank and he pointed out that the impedances are not the matter but the gains of the each channels are the matters (after considering the output impedance of the QPD channels).
If we assume the ideal voltage sources at the QPD and the symmetric output impedances of 50Ohm, the gain of the each circuit are affected but the change should be symmetric.

He found that several things:
- The analog switch (MAX333) used in the QPD unit adds more output impedance (somewhat randomly!).
- The resistance of the sum/diff circuits may vary each other unless we use 0.1% resistors.

In this evening I found that fb40m has been down, then I restarted fm40m successfully.

However there still is a problem, the reflective memory can not communicate with some front-end CPUs ( such as c1iscey, c1susvme, ...etc.)

Right now I don't have any ideas about this, I am leaving them as they are now .... we can deal with them tomorrow. 

The followers are what I did.

(1) ssh to fb40m then "pkill tpman"

(2) telnet to fb40m then typed "shutdown". ( These procedure are on the 40m wiki)

(3) make sure fb40m gets recovered while watching the medm screen C0DAQ_DETAIL.adl

(4) run the backup script in fb40m

(5) in order to fix the communication problem, physically turn off c1dcuepics and c0daqctrl

(6) keying some front-end CPUs. ---> still some of front ends indicate RED on the medm screen C0DAQ_DETAIL.adl ( figure attached )

 This is indeed sad. But, we can perhaps bypass all of this by just using the individual segment outputs. According to the circuit diagram and the c1iool0 .db file, we should be able to just do the math on the segments and ignore the VERT/HOR/SUM signals completely. In that case, we can just use high impedance for the sum/diff buffers as Koji says and not suffer from the calibration errors at all I think.

Unfortunately, the signals for individual segments also suffer from the voltage drop as all of the low impedance amplifiers are hung from the same input.
In order to utilize the individual channels, we anyway have to remove the resistors for the VERT/HOR/SUM amps.
That is possible. But does it disable some fast channels for future ASC purposes?

Nothing like a good ol' Bootfest to get back into the swing of things after vacation....

It was a regular bootfest, keying crates and running everyone's startup.cmd .  There wasn't any RFM funny business which we had been dealing with a lot earlier in December (maybe Kiwamu took care of that part of things last night).

After finishing the bootfest, I tried to re-enable the watchdogs.  I noticed that the optics weren't damping at all (not that any of them were swinging crazily, they just weren't damped like regular).  This was traced to the OSEM sensor inputs and outputs being disabled on all of the suspensions' screens.  I suspect that no burt-restoring happened after c1dcuepics was powercycled yesterday. 

All of the optics are now happy as clams.

MC2 is having a bad day, and I'm not yet sure why.  It's to do with the damping though.  When the damping is off, after a little while it will settle to ~30mV or so on the Watchdog screen.  When I enable all of the outputs and then turn on the damping, the optic gets kicked up.  It's like there's a minus sign error somewhere, maybe in a bad burtrestore?  This has been going on since I did my morning bootfest.

It's started to sit down and play nicely now.  Is someone doing magic remotely that is fixing things that I hadn't figured out yet?

The MCL path of MC2 was in a strange state as the filters were activated as if it is in lock even though we had no lock. So I manually ran "mcdown". This reset the filters of the MCL path.

Since it wasn't sure whether all the front-ends had been restored after the bootfest, I burtrestored everything to Dec 26 at 20:00.

Always keep in mind that to burtrestore c1dcuepics, the snapshot file has to be modified by hand by moving the last quote up to the line before the last.

I opened the auxiliary laser's shutter.

I'm currently working on the AP table.

 I finished working on the table.

I closed the AUX NPRO's shutter.

The HIGH and LOW channels are added into the burt request file "/target/c1losepics/autoBurt.req".

These values are used to colorize the alarm texts in the "C1DRIFT_MONITOR.adl" like a threshold. (the screenshot attached)

Hereafter these values will be automatically restored by the burt.  Happy !

We have installed the new Video Matrix.

Its still in an intermediate state, so don't try to "fix" anything before Kiwamu and I get back onto it in the afternoon.

The status so far is that we have removed the old switch (it was a 256 input x 128 output !! mux)  and installed the new one in the same rack. We have hooked it up to the CDS network and have set up its matrix by using the web interface (i.e. NOT EPICS).

Along the way, we discovered that there is lack of impedance matching in the video all over the 40m. Video signals are RF and need to be treated that way. The PSL signals are T'd around and sent on 50 Ohm cables to high impedance monitor inputs.

We should eliminate any switches besides the new one (called Luciana) and control the PSL's Video Monitor from the main MUX interface. No more Rogue Video Switches.

Another couple of things we have found is about RCR camera.

(1) The long cable which connects the RCR camera box and the video matrix doesn't work. Although the signal is alive and we can see it by the local tv monitor nearby PSL.

(1) The reflected beam going to the camera is too weak to see in the monitor.  We found a strange polarized cube splitter in front of the camera. We should modify it sooner or later.

Before we installed the video switch box, we also took some photos of it. We uploaded them onto the 40m Picasa.

Video Matrix

The first photo is the an entire view of the switch box. The following four photos are the details of the switch matrix.

 The slideshow below is a dump of the last several months of photos from the Olympus. The originals have been deleted.

I added 600 cc of Arrowhead Distilled Water to the chiller.

60 days plot shows that about every ~ 10 days I have to add some.

Please check the water level yourself.

This morning I found all the watchdogs had tripped during the night.

I restored them all.

I can't damp ITMX. I noticed that its driving matrix is all 1s and -1s as the the right values had been lost in some previous burtrestoring.

Rana fixed the problem. He found that the side damping was saturating. He lowered the gain a little for a while, waited for the the damping to slow down the optic and then he brought the gain back where it was.

He also upadted the MEDM screen snapshot.

The input channels of the cameras and the output channels for the monitors are summarized on the wiki.

The channel table on the wiki is very helpful when you want to make a change in the video matrix.

thank you.

The most up-to-date T and R plots for the Y1 and Y1S mirrors, as well as a T measurement for the ETM, can be found on:

http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_09/Optics/RTmeasurement

Using the techniques employed at LLO, and then by Rana here at the 40m a few weeks ago, Wiener filters have been installed on the inputs of all of the PEM IIR channels which are hooked up to the 110B PEM ADCU.  Some slight modifications have taken place to the code, and it's all been checked in to the 40m svn. 

I have installed the filters into:  All 6 Wilcoxon accelerometers, the Ranger seismometer, and one of the Guralps (GUR1).  The other Guralp is currently connected through the ASS/OAF machine's ADC, so it's not used in this test. The filters are all labeled "Wiener", and are FM1 in the C1:ASS-TOP_PEMIIR_## filter banks.

The first figure below is the output of the Wiener Filter calculation program.  It shows the uncorrected MC_L (black) and the corrected MC_L (red), using the optimal wiener filter.  This is as good as we should be able to do with these sensors in these positions.

The second figure is a DTT shot of me trying out the nifty new filters.  They seem to maybe do a teensy bit on the microseism, but otherwise it's a bit unremarkable.  Hopefully I'll get better subtraction during the day, when the base level for MC_L is higher.  Here, Black is uncorrected MC_L, Red is the corrected MC_L, Blue is the actuation channel, and green is an example seismometer channel to illustrate the ground motion at the time.

For posterity, since it's not all in one elog that I can find, the order of operations to install a Wiener Feed Forward filter is as follows:

1.  (When you can borrow the IFO) Take a very careful TF of the plant, between your actuation point and your error signal readout.  At the 40m, this means between C1:ASS-TOP_SUS_MC1_EXC and C1:IOO-MC_L, since we actuate by pushing on the MC1 coils.  At the sites / future 40m, this would be between the HEPI (or STACIS) and the error signal.  The limit of how good your Feed Forward can do will depend heavily on how good this TF is.  Coherence should be above ~0.95 for all points.  Export this data from DTT as a .txt file, using units "Complex (abs/rad)". 

2. Run fitMC12MCL.m (or equivalent wrapper file) to fit the transfer function you just took with some Poles and Zeros.  Make sure to edit the wrapper file with your new .txt file's name so you're getting a fresh TF (if you've just taken one).

3. (Again, when you can borrow the IFO) Run getMCdata.m (or equivalent) to fetch witness channel data and error signal data.  At the 40m, this usually means C1:IOO-MC_L, and witness sensors which are around the MC chambers.  This data should be taken at a time when the cavity is locked, but pretty much on it's own. (i.e. probably shouldn't have Common Mode feedback on the MC - so the MC should be locked, but not the full IFO, for example.)

4.  Run c1winoiir.m (the main program here, which contains some of these notes). This will take in the TF data you've fit, and the witness channel data you have, and calculate the optimal combination of Wiener filters for your witness channels.  It pre-filters your witness data by your TF, then calculates the Wiener filter.  The resulting FIR filters are saved in a file.

5.  Run firfit.m  This will take the FIR Wiener filters you've just created, and convert them conveniently to IIR filters, in a format to be copied directly into Foton.  For each witness channel, you'll get the IIR filter in 2 formats:  the first is for copying into the Foton .txt file (ex ASS.txt), and the second is for copying into the Foton gui, in the "Command" box on the filter design screen.  The "o" at the end of the copy-able filter indicates to Foton that it is a Z-Plane Online filter.  Copy filters appropriately (there should be a line preceding each set of SOS filter formats to indicate which channel this Wiener filter is for...these channel names are extracted from your getMCdata.m)

6. Save your Foton file, and update your Coefficients in MEDM.  Enable your outputs to actuators, and watch magic happen!

On the To-Do list:

Check the transfer of signal btwn PEMIIR matrix and the 9x1 'matrix' that sends the signals to the SUS inputs.  In the SimuLink, the input to the 9x1 matrix is a bundle of 8 numbers (the 8 outputs of the PEMIIR matrix), but it looks like it only pays attention to the first one.  Need to figure out how to make it realize that it's a bundle, not a single number. 

Also, the OAF up / down scripts don't seem to be working on any of the control room computers.  This needs to be checked in to / fixed (but not tonight....)

EDIT 6 Jan 2010:  Shouldn't have done this.  My bad.  The AA32 is on the other PEM matrix because the Adaptive code runs at 64Hz, so there's downsampling, calculating, and upsampling which goes on.  The Feed Forward path all runs at 2kHz, the regular rate of the ASS/OAF machine.  All of these filters are turned off (although I haven't deleted them from Foton).  Since we're focusing on low frequency stuff and trying to get that to do some subtraction, we're not worrying about the junk at higher frequencies just yet.

I have put AA32 filters into the PEMIIR matrix's input filter banks (ie, C1:ASS-TOP_PEMIIR_##), to match the ones that are in the same places in the regular PEM matrix on the OAF screen. 

I redid the uncorrected vs. corrected MC_L DTT printout, shown below. You can see that there's less junk at higher frequencies in the Blue (actuation channel) trace, which is good.

All the DAQ screens are bright red.  Thumbs down to that.

 All better now. 

Last night, we installed the VMI 5565 RFM card into Megatron.  After turning off the watchdogs for the ETMY optic, we disconnected the RFM fiber, and connected it to megatron, then powered it up. 

We modified the RCG code to have 3 rfmio blocks, which were reading 0x11a1c0 (ascPit), 0x11a1c4 (ascYaw), and 0x11a1c8 (lscPos).  These were connected to the approriate filter module inputs, and we also added grounds to the front of the rfmio blocks (we looked at the ass code which was setup that way, so we just did the same thing).  When we started it however, it didn't read properly.  If we turned off the input and set and offset, it calculated the output of the filter module correctly, (i.e. just the offset value), but as soon as we turned on the input, it was set to 0, no matter the offset value, which indicated it was reading something correctly.

After this test, the RFM fibers were reconnected to c1iscey, we rebooted c1iscey, and we confirmed that the system was working properly again.  We turned the watch dogs back on for ETMY.

Alex came over with a short RFM cable this morning.  We used it to connect the rfm card in c1iscey to the rfm card megatron

Alex renamed startup.cmd in /cvs/cds/caltech/target/c1iscey/ to startup.cmd.sav, so it doesn't come up automatically.  At the end we moved it back.

Alex used the vxworks command d to look at memory locations on c1iscey.  Such as d 0xf0000000, which is the start of the rfm code location.  So to look at 0x11a1c8 (lscPos) in the rfm memory, he typed "d 0xf011a1c8".  After doing some poking around, we look at the raw tst front end code (in /home/controls/cds/advLigo/src/fe/tst), and realized it was trying to read doubles.  The old rts code uses floats, so the code was reading incorrectly.

As a quick fix, we changed the code to floats for that part.  They looked like:

etmy_lsc = filterModuleD(dsp_ptr,dspCoeff,ETMY_LSC,cdsPciModules.pci_rfm[0]? *(\
(double *)(((void *)cdsPciModules.pci_rfm[0]) + 0x11a1c8)) : 0.0,0);

And we simply changed the double to float in each case.  In addition we changed the RCG scripts locally as well (if we do a update at some point, it'll get overwritten).  The file we updated was /home/controls/cds/advLigo/src/epics/util/lib/RfmIO.pm

Line 57 and Line 84 were changed, with double replaced with float.

return "cdsPciModules.pci_rfm[0]? *((float *)(((void *)cdsPciModules.pci
_rfm[$card_num]) + $rfmAddressString)) : 0.0";

. "  *((float *)(((char *)cdsPciModules.pci_rfm[$card_nu
m]) + $rfmAddressString)) = $::fromExp[0];\n"

This fixed our ability to read the RFM card, which now can read the LSC POS channel, for example.

Unfortunately, when we were putting everything the way it was with RFM fibers and so forth, the c1iscey started to get garbage (all the RFM memory locations were reading ffff).  We eventually removed the VME board, removed the RFM card, looked at it, put the RFM card back in a different slot on the board, and returned c1iscey to the rack.  After this it started working properly.  Its possible in all the plugging and unplugging that the card somehow had become loose.

The next step is to add all the channels that need to be read into the .mdl file, as well as testing and adding the channel which need to be written.

Alex added a new module to the RCG, for generating RFMIO using floats.  This has been commited to CVS.

This morning I've been having problems in trying to lock the X arm.

That doesn't seem to have solved the problem. The X arm can get locked but TRX slowly moves between 0.2 and 1.

The X arm is now locked with TRX stable at ~1.

I think earlier on today I was having problems with running the alignment scripts from op540. Now I'm controlling the IFO from Rosalba and I can easily and stably lock all degrees of freedom.

I needed the X arm to be locked to align the auxiliary beam of the AbsL experiment to the IFO. To further stabilize TRX I increased the loop gain from 1 to 1.5.

Now the auxiliary beam is well aligned to the IFO and the beat is going through the PRC. I'm finally ready to scan the recycling cavity.

I also changed the gain of the PRC loop from -0.1 to -0.5.

I have assembled the circuit and the control box for the quadrant magnetic levitation yesterday. The final setup is shown

in the figure below:

Due to my carelessness, I I connected the wrong ends of the power supply. I damaged 4 op-amp and one voltage 

regulator during this assembly. This stupid mistake spent me several hours to fix, and I got a bitter lesson;-(

Afterwards, I replaced those op-amps and reconnected the power supply . Kiwamu helped me and we measured

the transfer function of this circuit.  The transfer function agrees with  the specification in the schematics which

has a integrator below 1 Hz and a differentiator from 5 to 20 Hz. The bode plot for the measured transfer function

is the following:

Today I tested the photodetector parts and found that there is a mysterious oscillation. Whenever I connect the

photodector input A of the circuit (as indicated in the figure below),

the output of the op-amp has a 500k Hz oscillation shown up in the oscilloscope.This happens even A is disconnected from

the photodetector and connected to an open end wire. I don't know how to eliminate it, and its amplitude is so large (peak to

peak is around 2.5 V) which completely dominates the photodetector output. Does anybody has some ideas? Thanks.

1. Why do all of the BNCs have no GND connection? Each should have the individual cables to the ground. Each signal line and the corresponding ground line should be twisted together.

2. This looks the (usual) oscillation of the V-I conversion stage but I can't tell anything as I don't have the circuit diagram of the whole circuit.

3. In a certain case, putting some capacitance at the feedback may help. Read P.11 of the data sheet of LT1125. Try to put some capacitors from 20pF to some larger one whether it changes the situation or not. I suppose the bandwidth of your sensor can be ~1kHz. So putting a capacitance less than 10nF still has no effect to the servo.

 1. They are all connected to the box which has a single connection to the board ground. If I connect each of them to the ground, there would be many small loops

of ground. Of course, I should have replaced all the connectors such that the they are disconnected to the box as point out by Robert.

2. The oscillation disappears after I add 5 nF capacitor in parallel to the existing resistor. Thank you very much for pointing this out.

1. Yes. That is the bad. You should eventually replace the BNCs to the isolated ones.

2. OK. I like to emphasize again that everyone works on electronics should read data sheets more carefully and seriously because they have many important practical instructions to exploit full performance of the components. 

I'm working on the AbsL experiment. A measurement which involved the PRC locked is running at the moment.

Please make sure of not interfering with the interferometer until it is done. Thank you.

 I'm done for the moement.

I realized that I need to take into account somehow the DC power from the photodiode. By now the measurement of the transmitted beat's power is affected by the total power circulating inside of the PRC and thus it depends on the cavity alignment.

I closed the laser shutter and turned down the flipping mirrors.

I'm planning to restart measuring by 2.30pm today. Till then the interferometer is available.

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.

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.

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.

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

 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.

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.

(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.

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.

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.

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.

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.

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.