Dmass tells me that you have to record at least one channel.  ie at least one channel in your .ini file must be set to acquire, otherwise the DAQ will flip out.  It seems to be unhappy when you're not asking it to do things.

I continued on the STAND ALONE debugging of the megatron codes.

- I succeeded to run c1aaa with ADC/DAC. (c1aaa is a play ground for debugging.)

  The trick was "copy DAC block from sam.mdl to aaa.mdl".
  I don't understand why this works. But it worked.
  I still have the problem of the matrices. Their medm screens are always blank. Needs more works.

- Also I don't understand why I can not run the build of c1tst when I copy the working aaa.mdl to tst.mdl.

- The problem Joe reported: "# of channels to be daqed" was solved by

make uninstall-daq-aaa
make install-daq-aaa



  This command is also useful.

daqconfig

- Now I am in the stable development loop with those commands

killaaa
make uninstall-daq-aaa
make aaa
make install-aaa
make install-daq-aaa
make install-screens-aaa
startaaa


  I have made "go_build" script under /home/controls/cds/advLigo

usage:
./go_build aaa

- Note for myself: frequently visited directories

/home/controls/cds/advLigo/src/epics/simLink (for model)
/home/controls/cds/advLigo (to build)
/cvs/cds/caltech/target/c1aaa (realtime code log)
/cvs/cds/caltech/target/c1aaaepics (ioc log)
/cvs/cds/caltech/medm/c1/aaa (medm screens)
/cvs/cds/caltech/chans (filter coeffs)
/cvs/cds/caltech/chans/daq (daq settings)

I am still working on the c1aaa code. Now it seems that C1AAA is working reasonably (...so far).

1) At a certain point I wanted clean up the system status. I have visited /etc/rc.local to add c1aaa for realtime to non-realtime task

before:
/usr/bin/setup_shmem.rtl mdp mdc tst&
after:
/usr/bin/setup_shmem.rtl mdp mdc tst aaa&


   I rebooted the system several times.

sudo /sbin/reboot

2) I found that gabage medm screens accumulated in ~/cds/advLigo/build/aaaepics/medm after many trials with several simulink models.
This directory is always copied to /cvs/cds/caltech/medm/c1/aaa at every make install-screens-aaa
This caused very confusing MEDM screens in the medm dir like C1AAA_ETMX_IN_MATRX.adl (NOT ETMY!)

I did

cd ~/cds/advLigo
make clean-aaa


to refresh aaaepics dir. The current development procedure is

killaaa
make clean-aaa
make uninstall-daq-aaa
make aaa
make install-aaa
make install-daq-aaa
make install-screens-aaa
startaaa

3) Sometimes startaaa does not start the task properly. If the task does not work, don't abandon.
Try restart the task. This may help. 

killaaa
(deep breathing several times)
startaaa

What to do next:

- MEDM works

* make more convenient custom MEDM screens so that we can easily access to the filters and switches
* retrofit the conventional SUS MEDM to the new system

- once again put/confirm the filter coeffs and the matrix elements

- configure DAQ setting so that we can observe suspension motion by dataviewer / dtt

- connect the suspension to megatron again

- test the control loop

This afternoon, I tried to lock the interferometer again after a few days.

After a couple of failed attempts, and relocks of the MZ, the interferometer stayed locked continuously for about 50 minutes, with arm power of about 92.

I just wanted to check the status of the interferometer so I didn't do any particular measurement in the meantime.

ATM1: Seismometers are saturating, suspensions are OK

Atm2 : activity next door,  diesel Backhoe and diesel concrete cutter are running

Atm3: CES exhaust fans output  is pick up by 40M-Annex-North AC unit  intake. The 40m office room has some diesel smell...........see # 2377

In order to get the gige camera code running robustly here at the 40m, I created a "Yoichi style" ezcaread, which is now the default, while the original ezcaread is located in ezcaread.bin.  This tries 5 times before failing out of a read attempt.

By including a differentiator from 10 Hz to 50 Hz, we increase the phase margin and the resulting

magnetic levitation system is stable even without the help of eddy-current damping.

The new block diagram for the system is the following:

Here the eddy-current damping component is removed and we add an additional differential

circuit with an operational amplifier OP27G.

In addition, we place the Hall sensor below the magnet to minimize the coupling between

the coil and the Hall sensor.

The resulting levitation system is shown by the figure below:

I placed a GC750 gige camera looking at a pickoff of the AS port, basically next to the analog camera, on the AP table.

I've modified the main sitemap to include a CAM button, for the digital cameras.  There's a half done screen associated with it.  At the moment, it reports on the X and Y center of mass calculation, the exposure setting, and displays a little graph with a dot indicating the COM of mass location.  Currently this screen is associated a GC750 camera looking at pickoff of the AS port.  I'm having some issues with getting shell scripts to run from it, as well as a slider having limits other than 0 and 0.

Currently the Camera medm screen (now available from the sitemap), includes a server and client script buttons.  The server has two options.  One which starts a server, the second which (for the moment) kills all copies of the server running on Ottavia.  The client button simply starts a video screen with the camera image.  The slider on this screen changes the exposure level.  The snap shot button saves a jpeg image in the /cvs/cds/caltech/cam/c1asport directory with a date and time stamp on it (up to the second).  For the moment, these buttons only work on Linux machines.

All channels were added to C0EDCU.ini, and should be being recorded for long term viewing.

Feel free to play around with it, break it, and let me know how it works (or doesn't).

An interesting thing was happened in the OMC-LSC timing clock.

Right now the clock of the OMC and the LSC are completely synchronized.

 The trend data is shown below. At the first two measurements (Oct.27 and Nov.1),  LSC had constant retarded time of 3Ts (~92usec.).

The last measurement, on Nov.15, number of shifts goes to zero, this means there are no retarded time.

Also the variance between the two signal gets zero, so I conclude the OMC and the LSC are now completely synchronized.

The measurement on Nov.8 is somehow meaningless, I guess the measurement did not run correctly by an influence from megatron(?)

Dmass, Joe, Koji

A puzzle has been solved: Dmass gave us a great tip

"The RGC code does not work unless the name of the mdl file (simulink model) matches to the model name "

The model name is written in the second line. This is automatically modified if the mdl file is saved from simulink.
But we copied the model by using "cp" command. This prevent from the TST model working!

megatron:simLink>head tst.mdl
Model {
  Name                    "tst"
  Version                 7.3
  MdlSubVersion           0
...
...
...

This explained why the AAA model worked when the DAC block has been copied from the other model.
This was not because of the ADC block but the saving model fixed the model name mismatch!

Now our current working model is "C1TST". Most of the functionalities have been implemented now:

• The simulink model has been modified so that some of the functionalities can be accomodated, such as LSC/ASC PIT/ASC YAW.
• Some filter names are fixed so as to inherit the previous naming conventions.
• The SUS-ETMY epics screen was modified to fit to the new channel names, the filter topologies, and the matrices.
• The chans file was constructed so that the conventional filter coefficients are inherited.
• All of the gains, filter SWs, matrix elements have been set accordingly to the current ETMY settings.
• burt snapshot has been taken: /cvs/cds/caltech/target/c1tstepics/controls_1091117_024223_0.snap
burtrb -f /cvs/cds/caltech/target/c1tstepics/autoBurt.req -o controls_1091117_024223_0.snap -l /tmp/controls_1091117_024215_0.read.log -v

What to do next:

• Revisit Oplev model so that it accomodates a power normalization functionality.
• ETMY QPD model is also missing!
• Clean up mdl file using subsystem grouping

• Check consistency of the whitening/dewhitening switches.
• Connect ADC/DAC to megatron
• Test of the controllability
• BTW, what is happened to BIO?
• Implementation of the RFM card

Directories and the files:

• The .mdl file is backed up as
/home/controls/cds/advLigo/src/epics/simLink/tst.mdl.20091116_2100


• The default screens built by "make" is installed in
  /cvs/cds/caltech/medm/c1/tst/
They are continuously overridden by the further building of the models.


• The custom-built medm screens are stored in
/cvs/cds/caltech/medm/c1/tst/CustomAdls/

The backup is
/cvs/cds/caltech/medm/c1/tst/CustomAdls/CustomAdls.111609_2300/


• The custom-built chans file is
/cvs/cds/caltech/chans/C1TST.txt

The backup is
/cvs/cds/caltech/chans/C1TST.111609


• burt snap shot file
  /cvs/cds/caltech/target/c1tstepics/controls_1091117_024223_0.snap


The smell of diesel is particularly bad this morning.  Its concentrated enough to be causing me a headache.  I'm heading off to Millikan and will be working remotely on Megatron.

I have connected ETMY sus electronics to megatron ADC/DAC.
We continue this state until 15:00 of today. (Restored 13:00)

0) Now the connection for the ETMY suspension was restored in a usual state. It damps well.

1) I thought it would be nice to have dataviewer and DTT working.
   So far, I could not figure out how to run daqd and tpman.
   - I tried to configure
    /cvs/cds/caltech/target/fb/daqdrc
    /cvs/cds/caltech/target/fb/master
    /cvs/cds/caltech/chans/daq/C1TST.ini (via daqconfig)

   - I also looked at
    /cvs/cds/caltech/targetgds/param/tpchn_C1.par
   but I don't understand how it works. The entries have dcuids of 13 and 14 although C1TST has dcuid of 10.
   The file is unmodified.

   I will try it later when I got a help of the experts.

2) Anyway, I went ahead. I tried to excite suspension by putting some offset.

It seems to have no DAC output. I checked the timing signal. It seems that looks wrong clock.

   I looked at DAC output by putting 5000,10000,15000,20000,25000cnt to UL/UR/LR/LL/SD coils.
   I could not find any voltage out of the DAC in any channels.

   Then, I checked the timing signal. This clock seems to have wrong frequency.
   What we are using now is a clock with +/-4V@4MHz. (Differential)
   Maybe 4194304Hz (=2^22Hz)?

   I went to 1Y3 and checked the timing signal for 16K. This was +/-4V@16kHz. (Diffrential)

   The possible solution would be
   - bring a function generator at the end and try to input a single end 4V clock.
   - stretch a cable from 1Y3 to 1Y9. (2pin lemo)

OK. Now, Timing/ADC/DAC are working. It's almost there.

1) As a temporaly clock, I put a function generator at the back side of the ETMY.
Set it to the rectangular +/-4V@16384Hz. Connect it to D060064 PCIX Timing Interface Board in the IO Chasis.
That is a line receiver to feed the TTL signal into ADCs/DACs.

I confirmed the actual sampling clock is supplied to the ADC/DAC boards by looking at the SMB output of the D060064.

2) Restarted the realtime code.

3) I looked at DAC output by putting 5000,10000,15000,20000,25000cnt to UL/UR/LR/LL/SD coils again.
Yes! I could see the DAC channels are putting DC voltages.

4) Then I connected DAC CH0 to ADC CH0 using SCSI breaking up boards.
Yes! I could see the coil output switching change the ADC counts!

Now, we are ready to see the suspension damped. Check it out.

the inside temperature is alarming at the red level today - should check if the HIHI value is set correctly

[Rana, Jenne]

We opened up the little Thorlabs battery operated PD to see what was inside.  Rana took some pictures, and I drew a schematic (attached).  It's just a diode, biased with a battery (albeit a crazy 22.5V battery).

---------------
Comment by KA: PD is Hamamatsu S1223-01 Si PIN diode.

What a crazy battery. The main point is that it looks like this can be used for reasonable purposes: uses a load resistor on the BNC connector and you can use some pre-amp (e.g. Busby box or SR560) to have a low noise PD readout. You can also use the SR560 in its A-B mode as an 'opamp'. Ground the A input and the use a pole at 1 Hz and make the Output go into the B input through some large series resistor. The BNC from the PD gets Teed into the B input as well.

Then this becomes a transimpedance circuit readout of the diode, using the current noise of the SR560 as the limit.

Koji, Rana

The megatron DAC was temporaly connected to the suspension electronics for the DAC test. We went down to ETMY as we could not excite the mirror.

The DAC is putting correct voltages to the channels. However, the anti imaging filter test output does not show any signal.
This means something wrong is there in the DAC I/F box or the cables to the AI circuit. We will check those things tomorrow.

The ETMY was restored to the usual configuration.

It looked like the Busby Low Noise Box had too much low frequency noise and so I upgraded it. Here is a photo of the inside - I have changed out the 0.8 uF AC coupling cap with a big, white, 20 uF one I found on Rob's desk.

The Busby Box is still working well. The 9V batteries have only run down to 7.8V. The original designer also put a spare AD743 (ultra low current FET amp) and a OP27 (best for ~kOhm source impedances) in there.

Here's the noise after the fix. There's no change in the DC noise, but the AC noise is much lower than before:

I think that the AC coupled noise is higher because we are seeing the current noise of the opamp. In the DC coupled case, the impedance to ground from the input pins of the opamp is very low and so the current noise is irrelevant.

The change I implemented, puts in a corner frequency of fc = 1/2/pi/R/C = 1/2/pi/10e3/20e-6 = 0.8 Hz.

Overall, the box is pretty good. Not great in terms of current noise and so it misses getting an A+. But its easily a solid A-.

Had been disconnected for about two weeks.  I found a partially seated 4-pin LEMO cable coming from the OSEM PD interface board. 

I've measured the voltage noise of the SR560's lead acid battery outputs; they're not so bad.

Steve ordered us some replacement lead-acid batteries for our battery powered pre-amps (SR560). In the unit he replaced, I measured the noise using the following setup:

SR560                              Busby Box

(+12V/GND) -------------AC Input      Out  ----------------   SR785

The SR785 was DC coupled and auto-ranged. The input noise of the SR785 was measured via 50 Ohm term to be at least 10x less than the SR560's noise at all frequencies.

Its clear that this measurement was spoiled by the low frequency noise of the Busby box below 10 Hz. Needs a better pre-amp.

It appears the front panel for the DAC board is mis-labeled.  Channels 1-8 are in fact 9-16, and 9-16 are the ones labeled 1-8.  We have put on new labels to reduce confusion in the future.

Hurraaaah!
We've got the damping of the suspension.
The Oplev loops has also worked!

The DAC channnel swapping was the last key!

DataViewer snapshot to show the damping against an artificial excitation was attached

The circuit design of multi-resonant EOM have proceeded.

By using numerical method, I found the some best choice of the parameters (capacitors and inductors).

In fact there are 6 parameters (Lp, L1, L2, Cp, C1, C2) in the circuit to be determined.

In general the less parameter gives the less calculation time with performing the numerical analysis. Of course it looks 6 parameters are little bit large number.

In order to reduce the arbitrary parameters, I put 4 boundary conditions.

Each boundary conditions fixed resonant peaks and valleys; first peak=11MHz, third peak=55MHz, first valley=19MHz, second valley=44MHz.

So now the remaining arbitrary parameters successfully get reduced to 2. Only we have to do is optimize the second peak as it to be 29.5MHz.

Then I take C1 and C2 as free parameters seeing how the second peak agree with 29.5MHz by changing the value of the C1 and C2.

the red color represents the good agreement with 29.5MHz, in contrast blue contour represents the bad.

 You can see some best choice along the yellow belt. Now what we should do is to examine some of that and to select one of those.

/cvs/cds/caltech/target/fb/daqd -c daqdrc

This starts the FB.

Now the dataviewer and DTT work!

In designing the whole circuit it is better to know the characteristic of the EOM.

I made impedance measurement with the EOM (New Focus model 4064) and I found it has capacitance of 10pF.

This is good agreement with the data sheet which says "5-10pF".

The measured plot is attached below. For comparison there also plotted "open" and "10pF mica".

In the interested band( from 1MHz to 100MHz), EOM looks just a capacitor.

But indeed it has lead inductance of 12nH, resistance of 0.74[Ohm], and parasitic capacitance of 5.5pF.

In some case we have to take account of those parasites in designing.

How can I get those values from the figure?

 Instead of doing RCG stuff, I went to Millikan to work on data analysis as I couldn't stand the fumes from the construction.  (this morning, 8am) 

I added ~500 cc of distilled water to the laser chiller yesterday.

8 days plot: Thurdsay, Friday, Sat and Sun without construction

This is a continuation from last night, where Peter, Koji, and I were trying to get test point channels working on megatron and with the TST module.

Things we noticed last night:

We could run starttst, and ./daqd -c daqdrc, which allowed us to get some channels in dataviewer.  The default 1k channel selection works, but none of the testpoints do. 

However, awgtpman -s tst does appear in the processes running list.

The error we get from dataviewer is:

Server error 861: unable to create thread
Server error 23328: unknown error
datasrv: DataWriteRealtime failed: daq_send: Illegal seek

Going to DTT, it starts with no errors in this configuration.  Initially it listed both MDC and TST channels.  However, as a test, I moved the tpchn_C4.par , tpchn_M4.par and tpchn_M5.par files to the directory backup, in /cvs/cds/caltech/target/gds/param.  This caused only the TST channels to show up (which is what we want when not running the mdc module.

We had changed the daqdrc file in /cvs/cds/caltech/target/fb, several times to get to this state.  According to the directions in the RCG manual written by Rolf, we're supposed to "set cit_40m=1" in the daqdrc file, but it was commented out.  However, when we uncommented it, it started causing errors on dtt startup, so we put it back.  We also tried adding lines:

set dcu_rate 13 = 16384;
set dcu_rate 14 = 16384;

But this didn't seem to help.  The reason we did this is we noticed dcuid = 13 and dcuid = 14 in the /cvs/cds/caltech/target/gds/param/tpchn_C1.par file.  We also edited the testpoint.par file so that it correctly corresponded to the tst module, and not the mdc and mdp modules.  We basically set:

[C-node1]
hostname=192.168.1.2
system=tst

in that file, and commented everything else out.

At this point, given all the things we've changed, I'm going to try a rebuild of the tst and daq and see if that solves things.

I did a full make clean and make uninstall-daq-tst, then rebuilt it.  I copied a good version of filters to C1TST.txt in /cvs/cds/caltech/chans/ as well as a good copy of screens to /cvs/cds/caltech/medm/c1/tst/.

Test points still appear to be broken.  Although for a single measurement in dtt, I was somehow able to start, although the output in the results page didn't seem to have any actual data in the plots, so I'm not sure what happened there - after that it just said unable to select test points.  It now says that when starting up as well.  The tst channels are the only ones showing up.  However, the 1k channels seem to have disappeared from Data Viewer, and now only 16k channels are selectable, but they don't actually work.  I'm not actually sure where the 1k channels were coming from earlier now that I think about it.  They were listed like C1:TST-ETMY-SENSOR_UL and so forth.

RA: Koji and I added the SENSOR channels by hand to the .ini file last night so that we could have data stored in the frames ala c1susvme1, etc.

I tried rebooting megatron, to see if that might help, but everything still acts the same. 

I tried using daqconfig and changed channels from deactiveated to activated.  I learned by activating them all, that the daq can't handle that, and eventually aborts from an assert checking a buffer size being too small.  I also tried activating 2 and looking at those channels, and it looks like the _DAQ versions of those channels work, or at least I get 0's out of C1:TST-ETMY_ASCPIT_OUT_DAQ (which is set in C1TST.ini file).

I've added the SENSOR channels back to the /csv/cds/caltech/chans/daq/C1TST.ini file, and those are again working in data viewer.

At this point, I'm leaving megatron roughly in the same state as last night, and am going to wait on a response from Alex.

We want the elog process to run in verbose mode so that we can see what's going. The idea is to track the events that trigger the elog crashes.

Following an entry on the Elog Help Forum, I added this line to the elog starting script start-elog-nodus:

./elogd -p 8080 -c /cvs/cds/caltech/elog/elog-2.7.5/elogd.cfg -D -v > elogd.log 2>&1

which replaces the old one without the part with the -v argument.

The -v argument should make the verbose output to be written into a file called elogd.log in the same directory as the elog's on Nodus.

I haven't restarted the elog yet because someone might be using it. I'm planning to do it later on today.

So be aware that:

We'll be restarting the elog today at 6.00pm PT. During this time the elog might not be accessible for a few minutes.

 I tried applying the changes but they didn't work. It seems that nodus doesn't like the command syntax.

I have to go through the problem...

The elog is up again.

Steve is summarizing the Video Matrix choices into this Wiki page:

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

Requirements:

Price: < 5k$

Control: RS-232 and Ethernet

Interface: BNC (Composite Video)

Please check into the page on Monday for a final list of choices and add comments to the wiki page.

Alex checked out the old rts (which he is no longer sure how to compile) from CVS to megatron, to the directory:

/home/controls/cds/rts/

In /home/controls/cds/rts/src/include you can find the various h files used.  Similarly, /fe has the c files.

In the h files, you can work out the memory offset by noting the primary offset in iscNetDsc40m.h

A line like suscomms.pCoilDriver.extData[0] determines an offset to look for.

0x108000 (from suscomms )

Then pCoilDriver.extData[#] determines a further offset.

sizeof(extData[0]) = 8240  (for the 40m - you need to watch the ifdefs, we were looking at the wrong structure for awhile, which was much smaller).

DSC_CD_PPY is the structure you need to look in to find the final offset to add to get any particular channel you want to look at.

The number for ETMX is 8, ETMY 9 (this is in extData), so the extData offset from 0x108000 for ETMY should be 9 * 82400.  These numbers (i.e. 8 =ETMX, 9=ETMY) can be found in losLinux.c in /home/controls/cds/rts/src/fe/40m/.  There's a bunch of #ifdef and #endif which define ETMX, ETMY, RMBS, ITM, etc.  You're looking for the offset in those.

So for ETMY LSC channel (which is a double) you add 0x108000 (a hex number) + (9 * 82400 + 24) (not in hex, need to convert) to get the final value of 0x11a160 (in hex).

-----------

A useful program to interact with the RFM network can be found on fb40m.  If you log in and go to:

/usr/install/rfm2g_solaris/vmipci/sw-rfm2g-abc-005/util/diag

you can then run rfm2g_util, give it a 3, then type help.

You can use this to read data.  Just type help read.  We had played around with some offsets and various channels until we were sure we had the offsets right.  For example, we fixed an offset into the ETMY LSC input, and saw the corresponding memory location change to that value.  This utility may also be useful for when we do the RFM test to check the integrity of the ring, as there are some diagnostic options available inside it.

Alex tooked at the channel definitions (can be seen in tpchn_C1.par), and noticed the rmid was 0. 

However, we had set in testpoint.par the tst system to C-node1 instead of C-node0.  The final number inf that and the rmid need to be equal.   We have changed this, and the test points appear to be working now.

However, the confusing part is in the tst model, the gds_node_id is set to 1.  Apparently, the model starts counting at 1, while the code starts counting at 0, so when you edit the testpoint.par file by hand, you have to subtract one from whatever you set in the model.

In other news, Alex pointed me at a CDS_PARTS.mdl, filters, "IIR FM with controls".  Its a light green module with 2 inputs and 2 outputs.  While the 2nd set of input and outputs look like they connect to ground, they should be iterpreted by the RCG to do the right thing (although Alex wasn't positive it works, it worth trying it and seeing if the 2nd output corresponds to a usable filter on/off switch to connect to the binary I/O to control analog DW.  However, I'm not sure it has the sophistication to wait for a zero crossing or anything like that - at the moment, it just looks like a simple on/off switch based on what filters are on/off.

I added an integrator to increase the gain at low frequencies (below 5 Hz). In addition, I increased

the band of the differentiator. The schematics for both integrator and differentiator are the following:

The magnetic is stably levitated.

I turned off the light to get rid of 60Hz noise on the photodiode. I tried to measured the

open-loop transfer function of this setup, but somehow the SR560 is always saturate

when I injected the signal from SR785, which produces some weird results at

low-frequencies.

In addition, I found out that when the light is turned on, the levitation

can be stable even when I inverted the sign of the control loop. The control signal

on the osciloscope is the following:

This oscillator is around 120 Hz, which should be  the harmonics of 60 Hz from light pollution.

I am not sure exactly why it is stable when the control-loop sign is flipped. This could

be similar to the Pauli trap in the iron trap, because the coil not only provides a force

but also provides the rigidity. The sign of such rigidity depends on the sign of the control

current. If such oscillating rigidity changes at a frequency much higher than the response

frequency of the magnet, it will stablize  the system simply by significantly increasing

the inertial of the magnet.More investigations are essential to completely understand it.

For information about Pauli trap, one can look at the wikipedia:

http://en.wikipedia.org/wiki/Quadrupole_ion_trap

The 40m produces a large amount of paper and cardboard waste. It would be worth it if we disposed those kind of garbages for recycling.

I set up two new garbage bins in the lab: one in the control rooms that adds up to the can/bottle recycling bin, and one other one in the office area, next to the printer for general paper disposal.

People in the lab are strongly invited to make use of the two new garbage bins and recycle their paper and cardboard waste.

Boxes can be larger than the garbage bin, so I'd recommend people to crash them before throwing them into the bin.

I've changed the watchdog rampdown script so it brings the SUS watchdogs to 220, instead of the 150 it previously targeted.  This is to make tripping less likely with the jackhammering going on next door.  I've also turned off all the oplev damping.

[Sanjit, Jenne]

Sanjit and I are trying to put names to some signals which exist in SimuLink land, but which don't (yet) exist in EPICS land.  The deelio is that for each of the chosen SEIS signals in the ASS_TOP_PEM screen, the signal is split.  One part of the signal is used to decide how the adaptive filter should look, and the other part is actually used when doing the on-line subtraction.  Previously only the part of the signal which is used to decide on the Adaptive Filter could be seen on the screens, and had names. 

Before touching anything on the Simulink ASS.mdl, I did an svn check in, which put things at revision 36639. 

To try to make the desired signals exist, I put cdsFilt boxes (to create filter modules for each of these signals), and gave each of them a name (kind of like the Neverending Story....once they have a name, they'll exist).  My new names are C1:ASS-TOP_PEM_#_APPLY, which correspond to the previously-existing C1:ASS-TOP_PEM_#_ADPT (these are the ones that are along the top of the ASS_TOP_PEM matrix screen).  This version of the simulink model was checked in, and the svn is now at revision 36640.

We then did some "make clean", "make ass" and "make install-ass" action, and burt restored c1assepics, but nothing seems to be happening.  The screen doesn't have white boxes all over the place, and we didn't get any errors when we did the makes, and I'm sure we burt restored correctly (made sure the ASS GDS screen had a 1 in the lower left box etc), but all the values on the screen are still zero.  

When we ran the ass front end in terminal on the c1ass machine, we did see an error: "Invalid chan num found 2 = 30624" "DAQ init failed -- exiting".  I think this means that we need to have told some file somewhere that I was going to be adding 8 new channels. (maybe an .ini file?) Hopefully the Joe & Peter team can help us out with this, since they've been doing this kind of thing for the new system.

Moral of the story is, the new (non-working) simulink file has been svn checked in as revision 36640, and we're reverting to revision 36639, which was before I touched anything today.

This plot shows the RIN as measured by the ISS. Its ~2 x 10^-7, whereas its supposed to be more like 3 x 10^-8.

The ISS has DC coupled RIN channels (with a _F suffix) and AC coupled RIN channels (with a _FW suffix). By using a swept sine, Rob determined that the AC coupled channels have an AC coupling pole at ~80 Hz. The attached plot uses this and then has the overall gain adjusted to match with the _F channels below 10 Hz.

The _F channels can be converted directly into RIN by just dividing the spectra by the mean value of the time series. The dark offset of these channels is small and so this only introduces a ~5-10% calibration error.

Question #1: Why is the RIN so bad? According to the MEDM screen, the photocurrent on the MON/SENS PDs is 1.9/1.3 mA. That's sort of low, but should still allow us to get 5x10^-8 in RIN.

Question #2: Does it make an effect on the current DC Readout work? IF so, should we try to fix up the ISS in a temporary way? Since the in-loop and out-of-loop detectors are completely coherent, all of the noise is likely just unsuppressed noise from the laser. We are unable to increase the gain because of the high frequency noise from the NPRO.

Let's remember to replace this ISS with a new one that can drive an AOM. Need a volunteer to get us a new ISS.

 Here is a 7 years plot of  of the 40m temperature variations.

 Saturday's special event of braking up the large concrete pieces in CES bay was un event full.

 Composite video matrix switchers with 32 BNC in and 32 BNC channels out are listed.

As part of the fb40m restart procedure (Sanjit and I were restarting it to add some new channels so they can be read by the OAF model), I checked up on how the backup has been going.  Unfortunately the answer is: not well.

Alan imparted to me all the wisdom of frame builder backups on September 28th of this year.  Except for the first 2 days of something having gone wrong (which was fixed at that time), the backup script hasn't thrown any errors, and thus hasn't sent any whiny emails to me.  This is seen by opening up /caltech/scripts/backup/rsync.backup.cumlog , and noticing that  after October 1, 2009, all of the 'errorcodes' have been zero, i.e. no error (as opposed to 'errorcode 2' when the backup fails).  

However, when you ssh to the backup server to see what .gwf files exist, the last one is at gps time 941803200, which is Nov 9 2009, 11:59:45 UTC.  So, I'm not sure why no errors have been thrown, but also no backups have happened. Looking at the rsync.backup.log file, it says 'Host Key Verification Failed'.  This seems like something which isn't changing the errcode, but should be, so that it can send me an email when things aren't up to snuff.  On Nov 10th (the first day the backup didn't do any backing-up), there was a lot of Megatron action, and some adding of StochMon channels.  If the fb was restarted for either of these things, and the backup script wasn't started, then it should have had an error, and sent me an email.  Since any time the frame builder's backup script hasn't been started properly it should send an email, I'm going to go ahead and blame whoever wrote the scripts, rather than the Joe/Pete/Alberto team.

Since our new raid disk is ~28 days of local storage, we won't have lost anything on the backup server as long as the backup works tonight (or sometime in the next few days), because the backup is an rsync, so it copies anything which it hasn't already copied.  Since the fb got restarted just now, hopefully whatever funny business (maybe with the .agent files???) will be gone, and the backup will work properly. 

I'll check in with the frame builder again tomorrow, to make sure that it's all good.

[Jenne, Sanjit]

We would like several channels from the OAF/ASS screen to be saved to frames, so that we can use the channels for our OAF model.  In theory, this should involve uncommenting the desired channels in the .ini file (.../caltech/chans/daq/C1ASS.ini), and restart the frame builder.  Since this .ini file was generated a long time ago, and things have been changed since then, the chnnums in the .ini file and the corresponding .par file don't match up.  We need to go through the .par file (/cvs/cds/gds/param/tpchn_c3.par), and look up the chnnums for our channels, and copy those numbers into the .ini file.  Figuring out what was going on involved many fb40m restarts, but on the last one of the night, I restarted the backup script, so it should (hopefully) run tonight, and get all of the frames that we've been missing.

Notes to self: 

*  When adding channels to other front ends, the end of the process is to click the blue button on the C0DAQ_DETAIL screen next to your computer.  C1ASS isn't on that screen.  Instead, in the C1ASS_GDS screen, click DAQ Reload.

*  The channel names for the Test Points and the .ini files must be different.  That's why there's a '_2048' suffix at the end of every channel in our .ini file.

*  tpchn_C1 is all of the old-style system test points.  tpchn_C2 is the C1OMC, and tpchn_C3 is for the C1ASS testpoints.

*  When uncommenting channels in the C1ASS.ini file, make sure acquire is set to 1 for every channel we want saved.  The default in this .ini file is set to acquire = 0.

With Koji's help, I measured the length of the Mode Cleaner.

The new modulation frequencies (as quoted on the Marconi front panels) are: 

165.980580 MHz

 33.196116 MHz

132.784464 MHz

199.176696 MHz

The Frequency Counter readback is 165980584.101 Hz (a 4Hz difference).  All of the Marconi's front-panel frequencies read ###.##### MHz Ext, and the Frequency standard has it's "locked" light illuminated, and the 1pps input light blinking, so I think everything is still nicely locked to the frequency standard, and the frequency standard is locked to the GPS.

While changing the marconi's, I accidentally touched the MC's 29.5 MHz marconi.  It is set back to the nominal value (according to Kiwamu's rack photos) of 29.485MHz.  But the phase might be sketchy, although hopefully this doesn't matter since we don't do a double demodulation with it.

I also ran the scripts in the wiki page: How To/Diagonalize DRMI Length Control to set the DD Phases.