CANCELLED, WILL BE RESCHEDULED*

From time to time the 20 dB jump in the transfer function still occurs. The new AD8336 op amp did not change that issue. I am sure that the op amp was broken,

because the amplitude of the sine did not change when I turned the gain knob.

The above two curves were measured with different input amplitude of the sine from the spectrum analyzer. Nothing changed in between except that there was no

jump when Kiwamu was around. Very strange. Testing the electronic board led to no clue what is happening.

For now, I will just use the PDH box as it is, but one should keep this odd behaviour in mind.

[Katrin,Jenne]

RF photo diodes POP55 and POX11 are installed. The beams are aligned to the photo diodes.

I used 0.7 A/W for the response and 50V/A for POP55 according to elog page #4576.

To install the third RF photo diode we need to order a plano-convex lens with a focal length of 750 or

maybe even better 1000

The RF distribution box has been modified so that it generates two more 55 MHz LO signals.

After the modification I put the box back in place.

Then I checked the MICH and YARM locking quickly as a working test of the distribution box and it is working fine so far.

I will update the diagram of the RF distribution box (#4342) tomorrow.

(Motivation)

  Since we newly installed POP55 (#5743) an LO signal was needed for the demodulation.

However the RF distribution box didn't have any extra LO outputs.

Therefore we had to make a modification on the RF distribution box so that we can have a 55MHz LO signal for POP55.

Eventually I made two more 55MHz outputs including one spare.

(Modification)

The box actually had two extra output SMAs which had been just feed-thru connectors on the front panel without any signals going through.

In the box the modules consist of two categories; the 11MHz system and 55MHz system. I modified only a part of the 55MHz system.

The modification was done in this way:

  * split two branches of 55MHz into four branches by installing two new power splitters (ZMSC-2-1).

  * made and installed some SMA cables whose length were adjusted to be nicely fit in the box.

  * readjustment of the RF levels to 0-2 dBm at the outputs by replacing some attenuators.

  * checked the signals if all of them were happily coming out or not.

Also I found that the POX11 and POY11 demod boards were connected to the whitening filters in a wrong way.

The I and Q signals were in a wrong order. So I corrected them so that the upper inputs in the whitening filter is always the I signal.

(RF levels on 55MHz LO outputs)

Since the demod board requires a certain level of the RF signal as as LO, the LO signals have to be 0-2 dBm.

Here are the RF level in each 55MHz output after the adjustment of the level.

     AS55 =  0.76 dBm


     REFL55 = 0.76 dBm


     POP55 = 0.79 dBm


     spare = 0.83 dBm

Those numbers were measured by an oscilloscope and the oscilloscope was configured to measure the rms with the input impedance matched to 50Ohm.

In the measurement I used the actual input seed 55MHz signal from the RF generation box to drive the distribution box.

[Suresh, Mirko, Koji]

A cable from the stochmon box to the cross connect for the EPICS ADCs is installed.

The power supply and the signal outputs are concentrated in a single DSub 9pin connector
that is newly attached on the box.

The connection from the stochmon side of the cable and the EPICS value was confirmed.
The calibration of them looks fine.

To do:
- Once the stochmon box is completed we can immediately test it.
- The EPICS channel names are still as they were. We need to update the database file of c1iool0, the chans file for the slow channel.

The pinout is as following

-------------
| 1 2 3 4 5 |   Female / Inside View
\  6 7 8 9  /
 \---------/

1 - 11MHz Signal
2 - 30MHz Signal
3 - 55MHz Signal
4 - NC
5 - +5V supply
6 - 11MHz Return
7 - 30MHz Return
8 - 55MHz Return
9 - Supply ground

The diagram of the RF distribution box has been updated according to the modification ( #5744).

Both pdf and graffle files are available on the 40m svn : https://nodus.ligo.caltech.edu:30889/svn/trunk/suresh/40m_RF_upgrade/

Here shows the latest version of the diagram.

The amount of offsets in the LSC signals due to the RFAMs have been estimated by an Optickle simulation.

The next step is to think about what kind of effects we get from the RFAMs and estimate how much they will degrade the performance.

(Motivation)

(Results : Offsets in LSC error signals)

(Simulation setup)

For clarity, I also note the definition of PM/AM ratio as well as how the first order upper sideband looks like.

The attached PDF shows a possible gain / input noise config for the POP 22/110 that we would use to detect the RF power in the DRMI. Design is in the SVN.

If Kiwamu/Jenne say that this has good enough sensing noise for the lock triggering than we will build it. This is using a 2mm diode.

If we can get away with 1 mm, we might as well use a PDA10CF for now.

I found that the sum of the ITMX oplev signals had gone down to zero yesterday.

I checked the ITMX table and found two iris on the He-Ne laser path were blocking the beam on their apertures.

I guess this is because we were working around there for installation of POP/POX and may have touched some of the oplev optics.

Then I fully opened the apertures of those two iris and the sum went back to nominal of 600 counts.

Elog did not respond despite running the /cvs/cds/caltech/elog/start-elog.csh  script two times.  

It worked the after the third restart. 
 

Around 6PM on the 27th, I found that the C1:IOO-MC_RFPD_DCMON had risen to about 2.5V.   I checked the trend of MC2 sensors and found that  between 2PM and 6PM, MC2 had drifted in a strange way.  And also that the alignment had grown worse over several days.   I also noticed that the spot on the MC2F camera had shifted to the left.

I attempted to correct the alignment (decrease the C1:IOO-MC_RFPD_DCMON to ~0.5V ) by just moving the MC2 and succeeded!! So it is quite likely that most of the slow MC drift is arising due to MC2 table drift.

I decided to try and close the MC2_TRANS QPD to MC2 loops separately to see if MC alignment becomes stable  But several screens needed to be fixed before we could try anything.   So I fixed C1IOO_WFS_MASTER,  C1IOO_WFS_INMATRIX and ...OUTMATRIX screens.  Deleted the older ones to avoid confusion.

In this process I noticed that the directory of $screens$/c1mcs/master contains copies of older C1SUS_MC1 , 2. and 3 screens which look very similar to the new autogenerated screens.  Some of the links in the WFS screens were pointing to the old screens.  I have redirected the links and I will delete these in a couple of days, if no one objects.

(POX)

The POX beam had been 80% clipped at a black glass beam dump of the POX11 RFPD.

I steered the first mirror in the POX path to fix the clipping. Then the beam was realigned onto the RFPD.

However the beam is still very close to the black glass, because the incident angle to the second mirror is not 45 deg .

We need to refine the arrangement of the POX11 optics a bit more so that the beam will never be clipped at the black glass.

(POP)

 The POP optics also need to be rearranged to accommodate one more RFPD.

Additionally Rana, Suresh and I discussed the possible solutions of POP22/110 and decided to install a usual PD (PDA10A or similar) instead of a custom-made.

So a plan for the POP detectors will be something like this:

        + design an optical layout.

        + buy a 2 inch lens whose focul length is long enough (#5743)

        + rearrange the optics and install POP22/110

        + lay down a long SMA cable which sends the RF signal from POP22/110 to the LSC rack.

        + install a power splitter just before the demod board so that the signal is split into the 22MHz demoad board and 110MHz demod board.

           => make sure we have a right splitter for it.


        + install a band pass filter after the power splitter in each path.

           => A 22MHz band pass filter is already in hand. Do we have 110MHz band pass filter somewhere in the lab ?

The picture here shows the latest configuration on the ITMX table.

Here is an actual time series of the I and Q signals in dataviewer. The I signal outputs just junk while the Q showed a nice sine curve.

Status update on the LSC activity:

I've installed Control System Studio (CSS) on pianosa, from the version 3.0.2 Red Hat binary zip.  It should be available as "css" from the command line.

CSS is a new MEDM replacement. It's output is .opi files, instead of .adl files.  It's supposed to include some sort of converter, but I didn't play with it enough to figure it out.

Please play around with it and let me know if there are any issues.

links:

• http://cs-studio.sourceforge.net/docbook/
• http://sourceforge.net/apps/trac/cs-studio
• http://ics-web.sns.ornl.gov/css/updates/apps/epics_css_3.0.2-linux.gtk.x86_64.zip

 So far I've only given it about half an hour of my time, but it is *really* frustrating so far.  There don't seem to be any instructions on how to tell it what our channels are / how to link CSS to our EPICS databases.  Or, the instructions that are there say "do it!", but they neglect to mention how...  Also, there exists (maybe?) an ADL->BOY converter, but I can't find any buttons to click, or how to import an .adl, or what I'm supposed to do.  Also, it's not clear how to get to the editor to start making screens from scratch. 

It looks like it has lots of nifty indicators and buttons, but I would have felt better if I had been able to do anything.

Another thing that is going to be a problem:  the Shell Command button that we use all over the place in our MEDM screens is not supported by this program.  It's listed in the "limitations" of the ADL2BOY converter.  This may kill the CSS program immediately.  Jamie: did Rolf/anyone mention a game plan for this?  It's super nice to be able to run scripts from the screens.

Moral of the story:  I'm annoyed, and going to continue making my OAF screens in MEDM for now.

Suresh showed me a cool script that Mirko made, but didn't elog about.

You tell the script what filter banks you want, and it creates a screen for each with a bunch of different filter module display formats.  Then you can copy the format you like into the actual screen you're modifying. 

Currently PEM, LSC and IOO (and maybe others?) have "fmX" folders inside their medm/c1.../master folders.  For each subsystem, we need to copy this folder, and modify the generic .adl file so that it puts in the correct subsystem letters.  Once this is done, you can just run the generateFMscreens.py after putting in your filter bank names.

 Wasn"t me.

I was lucky to notice that the nitrogen supply line to the vacuum valves was leaking. Closed ALL valves. Open supply line to atm. Fixed leak. 

This was done fast so the pumps did not have to be shut down. Pressurized supply line and open valves to

"Vac Normal" condition in the right sequence.

{Suresh, Jamie, Mirko]

We adapted the Stochmon box to include LP filters at 1.8Hz behind the RMS parts.
Then measured the RMS signals for different RF signal levels at 11.0.65, 29.5, 55.325MHz provided by a RF freq. generator.
As you can see in the data below the suppression of the BP filters of neighboring frequencies is only 35-35dB in power (see also manufacturer specs).

We therefor want to substract crosstalk, by calculating it out. We decided to use C-code in CDS. No computer crashing this time :)

We however ran into the problem that the RMS signal channels are acquired by the slow (EPICS) maschine c1iool0. Channels are (C1:IOO-RFAMPD_33MHZ , -"-133MHZ, -"-166MHZ) and we could not access those in the CDS c1ioo model. Using the EpicsIn block we got an CA.Exception stating that the variable was hosted on multiple servers. We then tried to use the EzcaRead to access the variables. Got an compile error, about the compiler not beeing able to connect all parts. It seems that the EzcaRead left behind a "ghost" part in the model (something with M1:SYS-FOO_BAR which is the default naming of the EzcaRead block) even after we deleted that block. We toyed around with the /opt/rtcds/caltech/c1/chans/daq/C1EDU_IOO.ini  and  /cvs/cds/caltech/target/c1iool0/ioo.db  files. We tried to uncomment the "old" (33,133,166) channels there to get rid of the conflict, but that didn't work.

We want to write the outputs to C1:IOO-RFAMPD_11MHZ , -"-29MHZ, -"-55MHZ EPICS channels.

We had to get the model back from the svn to get it running again.

I have fixed the WFS_MASTER screen and several of the subscreens such as the MCASS and MC_WFS_LKIN.

Since MC_WFS_LKIN uses six demodulators and single oscillator I could not use the automatically built Lockin screens. 

I built one using the compact filter banks mentioned earlier

The phases in the WFSlockins have yet tp be set.

I have shifted the alignment of the MC suspensions such that the PZT won't rail.

Since I didn't care of the spot positions on the MC mirrors, currently they are terribly off from the centers.

After the shift, I realigned the Stochmon PD again.

The attachments below shows the alignment of MC and PZTs before shifting the just for a record

[Kiwamu, Mirko]

Non-optimal 11MHz SB frequency causes PM to be transformed into AM.
m_AM / m_PM = 4039 * 1kHz / df , with df beeing the amount the SB freq. is off.

Someone might want to double check ths.

 This is neat idea, but it seems like it would be easier to just add another set of rf BP filters inside of the StochMon box. Luckily, Steve was thinking ahead and ordered extra filters.

I finally got around to wrapping up the SUS input matrix diagonalizer. The files I have added to ...scripts/SUS/peakFit are:

• kickAll: Restores all SUS angle biases using /cvs/cds/rtcds/caltech/c1/medm/c1ifo/cmd/C1IFO_OPTICrestore.cmd XXXX &, then runs 'freeswing all'. Finally, writes an elog entry with the time when the optics were kicked and saves the gps time to 'kickAll.time'.
• diagAllSUS.m: An M-file that calls all the other individual M-files needed for the matrix generation. What it does:
  • Reads kick time from kickAll.time
  • Runs getSensors.m to get time series from all optics' sensors
  • Runs makeSUSSpectra.m to generate spectra from time series
  • Runs findPeaks.m to fit spectra for peak frequencies
  • Loops through all optics and runs, in sequence:
    • inmat = findMatrix(XXXX) to generate the matrix for each optic
    • writeSUSinmat(XXXX,inmat) to write that matrix to the frontend
• diagAllSUS: A wrapper for diagAllSUS.m. It also writes an elog entry and attaches the pre and post spectra demonstrating the diagonalization. The entry following this one is an example.

The following lines should eventually be added to the controls@nodus crontab:

0 8 * * 0 /cvs/cds/rtcds/caltech/c1/scripts/SUS/peakFit/kickAll

0 18 * * 0 /cvs/cds/rtcds/caltech/c1/scripts/SUS/peakFit/diagAllSUS

(i.e., do the kick at 8am on Sundays and run the diagonalization 10 hrs later at 6pm). They can be done on a different machine but then my elog commands will need to be modified.

Before we add them, we should check that they do, in fact, work. We can do this sometime while I'm at the 40m this week.
 

The PMC HV drops off more offen lately.

Today, I could lock the YARM laser for 2h to the YARM cavity. After to hours the output of the servo is saturated. I need to work on thermal feedback to the laser.

It is a nice TEM00 mode and the green light enters PSL table.

Measured with pin-ball machine spectrum analyzer (I forgot the real name, but it is the one that makes sounds like a pin-ball machine), source power10mVp, Lb1005 gain 2.05.

Setup

Input offset of LB1005 is zero

Locking history

On Thursday, Oct 27, lock for 3 min

On Friday, Oct 28, lock up to 18 min, improvements done by

• finding the right adjustment of PI Corner frequency and gain
• better alignment of the light to the cavity
• I used a high-pass filter between LO and LB1005, but no improvement of lock. In contrast, it got worse.

On Monday,Oct 31, careful adjustment of summing box (rear of of LB1005), lock up to 2h, limited by saturated feedback signal --> work on slow control

Some more plots

I actually tried to do this last night, but I was getting a terminal error from nodus. Jamie told me to just manually redefine the TERM variable and it would work. So, I have added kickAll and diagAllSUS to controls@nodus's crontab:

nodus:~>crontab -l

0 5 * * * /opt/rtcds/caltech/c1/scripts/backup/rsync.backup

0 7 * * * /opt/rtcds/caltech/c1/scripts/backup/check_backup.sh 

0 17 * * 0 /cvs/cds/caltech/users/jenne/LIGOX/LIGOX_Pizza_Reminders.sh

0 8 * * 0 /cvs/cds/rtcds/caltech/c1/scripts/SUS/peakFit/kickAll

0 18 * * 0 /cvs/cds/rtcds/caltech/c1/scripts/SUS/peakFit/diagAllSUS

Shade 12 black glass-green lines: 1/8" thick,  6" wide  x 7 " high  mounted on angle bracket below.  Aperture 1" diameter. Let me know what do you think.

[Mirko, Jenne]

I finished (mostly? maybe?) the OAF screens.  They're pretty awesome. 

While we were playing with the OAF, trying to do some oafing, the output of the code decided to just be zeros.  We did a test, and in the c-code set the output to be a constant value, and that worked.  But when we put it back to normal (being adaptive) and recompiled, it still only outputs zeros.  The code is receiving both witness and error signals, so we don't know what's going on.

In the course of trying to make things work again, we did a complete reboot of c1lsc and c1sus.  Did a burt restore.  Everything (except our weird code problem) should be fine again.  Optics are damping happily.

I horizontally swept the translation of the incident beam in order to investigate a possible clipping in Power-recycled Michelson (PRMI).

The recycling gain of PRMI depended on the beam pointing but it did't improve the recycling gain.

I guess the amount of the entire shift I introduced was about +/- the beam diameter = +/- 5 mm or so.

Within the range of about +/- 5mm in the horizontal beam translation I didn't find any obvious sign of a clipping.

(Measurement)

(Results)

Here shows the measured recycling gain and the power reflectivity of PRMI as a function of the beam pointing.

 Actually there was an error.

For 11MHz it is:
m_AM / m_PM = 2228 * 1kHz / df

For 55MHz:
m_AM / m_PM = 99.80 * 1kHz / df

see PDF

It turns out that nodus doesn't know how to NDS2, so I can't run diagAllSUS as a cron job on nodus. To further complicate things, no other machines can run the elog utility, so I am going to have to do something shifty...

 Actually in the last 40m meeting we discussed the SUS diagnosis and decided not to post the results on the elog.

Alternatively we will have a summary web page which will contain all the information (sensitivity, UGF monitors, etc.,) and will be updated everyday like GEO.

This will be a place where we should post the SUS results every week.

So we don't need to worry about the cron-elog job, and for running the scripts you can simply use one of the lab machines as a cron host.

Once you get the scripts running on a machine as a cron job, it will be the point where we should quit developing the SUS diagonalizer and pass it to the web summary people.

The possible explanation to this effect is the following:

Seismic noise mainly consists of the Love and Rayleigh surface waves. In the simulations we've taken 2 perpendicular Love waves and 2 perpendicular Rayleigh waves that interfere under the test mirrors. This interference produces both translational and tilt movements. Then we can see the coherence between translational motion and cavity length.

1. The coherence at big frequencies is small due to the passive isolation.

2. The coherence at 1 Hz is 0 due to the wire resonance.

3. The coherence between 1 and 10 Hz is reasonable. At the real 40m's measurements we can see only good coherence for gur1_x and sts1_x but this is the matter of adjusting seismic waves amplitude and direction. In the simulation we've assumed that all waves are of the same amplitude. The really interesting thing is that

4. The coherence below 0.8 Hz began to grow. We don't see this in real measurements.

But let's simulate the seismometer measurements. It measures not only translational motion but also tilt and with amplitude proportional to g / omega^2. On the Figure below the spectrum of translation motion, tilt and tilt as seen by seismometer is presented. We can see that at low frequencies tilt begins to dominate over the translational motion. We assumed the speed of waves in the region 30 - 60 m/sec.

Let's now plot the coherence between the cavity length and seismometer signal.

We can see that the coherence between seismic signal from measured by seismometer and cavity length is gone below 1 Hz where tilt becomes important.

Now let's try to filter out the seismic noise from the cavity length using both static Wiener filtering and adaptive Mfxlms algorithm. For both filters we've used AA filter before the filters and also AI filter after adaptive filter. The downsampling ratio was 4, the sample frequency 256. We can see that nothing is really subtracted due to the pollution of the seismometer signal due to tilt motion.

Assume we do the same computational experiment but with the seismometers that measure only ground translational motion and tilt do not affect on them. Then we have a reasonable subraction of seismic noise at low frequencies even with the filters of the length 100 as shown on the figure below.

Let's look through an order of magnitude analysis. Assume ground motion consists of only one wave with amplitude A and only vertical movement:  z(t) = A*sin(2 pi 0.1 t). So the frequency of the wave is 0.1 Hz. If A = 10-6 m => the amplitude of the suspended mirror motion is also approximately 10-6 m, as we have no isolation at low frequencies. The tilt angle has the amplitude alpha = 2*pi*A/lambda, where lambda - wavelength of the ground wave, lambda = v/f = 40/0.1 = 400 m, v - speed of the wave, f - frequency. Then alpha = 10-8 rad. If the distance between ground and mirror suspension point is 1 m, then mirror motion amplitude due to tilt is B = 10-8 m << A. 

It turns out that tilt does not effect much on the cavity length compared to the ground translational motion, but it affects a lot on the seismometer signals, that are used as witness signals in the filtering. For that reason we need tiltmeters to filter seismometer signals in order to obtain pure translational ground motion.

I was trying to give Allegra a second head, and it didn't quite work.  It's still in progress.  Steve, you might not like how I've 'mounted' the second monitor, so we can talk about something that might work tomorrow.

EDIT: Ran Jamie's NDS2 reset method and it's still not serving up MC data.

I am debugging the SUS input matrix diagonalization code (which I have affectionately termed "Dr. SUS") offline by running everything except the actual writing of the matrices (%writeSUSinmat()) in a sandbox directory. Some notes:

• nodus doesn't know NDS2, but this isn't a problem given Kiwamu's reply, since we don't want to push results to the elog. I will still have the script push "optics kicked---don't touch" alerts to the elog, but I realized this can be done easily from a remote computer via in-script SSH commands. My next choice was pianosa, but even though she knows NDS2, she spits out MEX errors when I try to get data. Third stop was allegra, and she plays nice 
• NDS2 is unable to read the MC mirror sensor data. Data from all other optics are retrieved without a problem. I verified that raw data was being written by plotting playback data in dataviewer, and I tried various times and the problem persisted. I suspect the problem is on the NDS2 server side:

The most recent entry in .../users/jzweizig/nds2-mafalda/channel_history shows nothing for MC1 2 or 3

I did some messing around with the NDS2 config and channel files and things seem to be working as expected... for now. SENSOR channel data can be acquired for all sensors on all hanging optics.

What I did:

• NDS2 gets its channel lists from .../users/jzweizig/nds2-mafalda/nds2.conf, which is called in the start-nds2 script. Within this, there are channel.file lines that specify which channels are available for raw and trend data. The four files that were listed were:
  • C-R-raw-channel_list.txt
  • C-M-ChanList.txt
  • C-T-ChanLIst.txt
  • C-R-online-channel_list.txt (this one was listed after a hashed line, which was suspicous---see below)
• I noticed that a grep for SENSOR only returned lines for non-MC mirrors in both "R" files
• I also noticed that calling NDS2_GetChannels('mafalda.martian:31200') did not return any non-suffixed (i.e., raw) channel names for MCx_SENSOR channels, while non-MC SENSOR channels each had two non-suffixed listings. I thought this was strange.
• I manually added the line "C1:SUS-MC1_SENSOR_UL 0 real_4 2048 C-R" to one of the "R" channel files, then restarted the NDS2 server, and that channel was still not served. I figured that the second "R" channel file might have been left in the config file as a mistake, so I commented it out, restarted the NDS2 server, and was able to get MC1_SENSOR_UL data. I have left the comment-out there, with a signed EDIT.
• Wary of (and too lazy to) manually add lines for all 5 sensors for each MC mirror, I decided to try generating a channel file using the most recent .gwf file in the frames, as indicated in Joe and John's elog post. To do this, while in .../nds2-mafalda/, I ran:
  • /cvs/cds/caltech/users/jzweizig/nds2-server/bin/buildChannelList /frames/full/10042/C-R-1004246528-16.gwf > C-R-raw-channel_list.txt
• A grep for SENSOR in the new C-R-raw-channel_list.txt now returned lines for all MC mirror sensors... BUT NOT FOR ETMY(?!). I tried some slightly older .gwf files (all from today), but the ETMY files never showed up. I had no choice but to enter them manually. Another odd thing is that the channel file generated this way seems to be fairly jumbled up, in the sense that there is no clear top-town order (e.g. SUS-BS_blah then SUS-ETMX_blah). Instead, some SUS-BS channels are here, some are after SUS-ETMX or SUS-PRM channels, etc. Look at the file to know what I mean.
• The original raw channel file is there as C-R-raw-channel_list.txt.bak.1004247481.

In any case, as I said, everything appears to be working now, but as soon as we try to generate a new channel file using the prescribed means, there will inevitably be channels omitted. Someone who knows more than me should get to the bottom of this and wiki a strict, detailed procedure for how this is to be done.

Now that NDS2 is working, I was able to run all parts of diagAllSUS (except for the matrix writing) without errors. Barring issues with standard commands (freeswing, turnOnWatchDogs.csh, caput, etc.), Dr. SUS should be ready to go.

As requested, I have suppressed the generation of an elog post containing the results of the diagonalization.

Dr. SUS will run on allegra as a cron job at 8:00am on Sundays:

allegra:peakFit>crontab -l

PATH=/bin/:/usr/bin/:/cvs/cds/caltech/apps/linux64/matlab/bin/:/cvs/cds/caltech/apps/linux/gds/bin/:/cvs/cds/caltech/apps/linux/tds/bin/

PWD=/cvs/cds/caltech/apps/linux/gds/lib/

LD_LIBRARY_PATH=/cvs/cds/caltech/apps/linux/gds/lib

01 05 * * 0 cat /cvs/cds/caltech/users/kiwamu/work/20091026_OMC-LSC-diag/src/OMC_LSC_timing.m | matlab -nosplash -nodesktop > /dev/null

0 8 * * 0 /cvs/cds/rtcds/caltech/c1/scripts/SUS/peakFit/runDrSUS

Also: should these variable definitions really be here?

 I locked the PMC and MC resonated in TM00 right on. Than I started checking anchoring screws with the torque wrench.

B,  3/8 foor bolts were tight, They were set  to 50 ft/lbs

C,  dog clamp bolts were tight at 80 ft/lbs

D,  horizontal position locks were lose. They were locked by finger.

E,  below covers were reset not to short

The MC is locking in TM01 mode now 

They were traced and labeled. One goes to 1X2 and the other to AS-ISCT. They are Andrew Heliax 1/4" od. made by CommScone,  model number FSJ1-50A

Cron starts with only a very minimal PATH.  However, this shouldn't be an issue if you specify the full path to the commands.

The rest of the env vars should probably not be there.

Also, Zach:  using /cvs/cds is now forbidden.  We need to put this script in the right place.

Elog was hanging, restarted with the script.

Slight modification on that model:

• terminated Q_out of Lockins to be able to compile the old model
• assigned other ADC channels to GCY (green YARM)

connector J9B of hardware ADC --> ch1 in software ADC --> GCY_ERR

connector J14 of hardware ADC --> ch11 in software ADC --> GCY_PZT

connector J15 of hardware ADC --> ch13 in software ADC --> GCY_REFL_DC

[Steve / Kiwamu]

Channels C1:X05-MADC0_TP_XXX with XXX 2-9, 14-19, 21-27, 29-31 showed digital zeros.

Some of these channels are used in c1scy.mdl, e.g. for OSEM stuff. I guess this is not optimal...

I changed an ADC channel for GCY_ERR and thus recompiled the c1scy model.