Both Rolf and Alex (at least his elbow) together visited the 40m to talk with Joe for the CDS.

40m is the true front line of the CDS development!!!

We got two small RF filter for the PMC from Valera  They are made by http://www.larkengineering.com/   "MC35.5-3-AB" sma, 29300-01

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

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

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

Around noon, Yuta and I were trying to figure out why we were getting no signal out to the mode cleaner coils.  It turns out the mode cleaner optic control model was not talking to the IOP model. 

Alex and I were working under the incorrect assumption that you could use the same DAC piece in multiple models, and simply use a subset of the channels.  He finally went and asked Rolf, who said that the same DAC simulink piece in different models doesn't work.  You need to use shared memory locations to move the data to the model with the DAC card.  Rolf says there was a discussion (probably a long while back) where it was asked if we needed to support DAC cards in multiple models and the decision was that it was not needed.

Rolf and Alex have said they'd come over and discuss the issue.

In the meantime, I'm moving forward by adding shared memory locations for all the mode cleaner optics to talk to the DAC in the c1sus model.

Note by KA: Important fact that is worth remembering

(Rana, Yuta)

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

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

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

This problem has been resolved.

Apparently during one of Alex's debugging sessions, he had commented out the feCode function call on line 1532 of the controller.c file (located in /opt/rtcds/caltech/c1/core/advLigoRTS/src/fe/ directory).

This function is the one that actually calls all the front end specific code and without it, the code just doesn't do any computations.  We had to then rebuild the front end codes with this corrected file.

Currently trying to understand why the ssh connections to c1sus  are flaky.  This morning, every time I tried to make the c1sus model on the c1sus machine, the ssh session would be terminated at a random spot midway through the build process.  Eventually restarting c1sus fixed the problem for the moment.

However, previously in the last 48 hours, the c1sus machine had stopped responding to ssh logins while still appearing to be running the front end code.  The next time this occurs, we should attach a monitor and keyboard and see what kind of state the computer is in.  Its interesting to note we didn't have these problems before we switched over to the Gentoo kernel from the real-time linux Centos 5.5 kernel.

Our new undergrad Joonho Lee received 40m specific basic safety training yesterday.

Yuta and Joonho are scheduled to participate in the LIGO-laser safety tutelage with Peter K on Oct 12

 I put some optics to get the green SHG on the PSL table.

Now a green light successfully comes out from the doubling crystal.

Since the optical layout of the PSL table was dramatically changed, I had to re-setup the green SHG stuff. 

 - what I did

I put a steering mirror after the 90/10% pick off mirror, and then a half wave plate and a convex lens.

The lens is approximately on the right place.

 To get the green beam easily, temporarily I raised the current of the NPRO up to 2 A.

I connected the oven to the heat controller, set the temperature to 36.8 deg which is the set point previously used.

After putting and aligning the oven, I finally obtained the green beam.

At the end of the work I set the NPRO current back to 0.9 A and relocked the PMC.

- things to be done

 1. more precise mode matching

 2. optimization of the temperature 

At the moment, c1sus and c1mcs on the c1sus machine seem to be dead in the water.  At this point, it is unclear to me why.

Apparently during the 40m meeting, Alex was able to get test points working for the c1mcs model.  He said he "had to slow down mx_stream startup on c1sus".   When we returned at 2pm, things were running fine. 

We began updating all the matrix values on the medm screens.  Somewhere towards the end of this the c1sus model seemed to have crashed, leaving only c1x02 and c1mcs running.  There were no obvious error messages I saw in dmesg and the target/c1sus/logs/log.txt file (although that seems to empty these days).  We quickly saved to burt snap shots, one of c1sus and one of c1mcs and saved them to /opt/rtcds/catlech/c1/target/snapshots directory temporarily.  We then ran the killc1sus script on c1sus, and then after confirming the code was removed, ran the startup script, startc1sus.  The code seemed to come back partly.  It was syncing up and finding the ADC/DAC boards, but not doing any real computations.  The cycle time was reporting reasonably, but the usr time (representing computation done for the model) was 0.  There were no updating monitor channels on the medm screens and filters would not turn on.

At this point I tried bringing down all 3 models, and restarting c1x02, then c1sus and c1mcs.  At this point, both c1sus and c1mcs came back partly, doing no real calculations.  c1x02 appears to be working normally (or at least the two filter banks in that model are showing changing channels from ADCs properly).  I then tried rebooting the c1sus machine.  It came back in the same state, working c1x02, non-calculating c1sus and c1mcs.

Awhile ago I wrote several scripts for reading in medm screen matrix settings and then writing them out.  It was meant as kind of a mini-burt just for matrices for switching between a couple of different setups quickly.

Yuta has expressed interest in having this instruction available.

In /cvs/cds/caltech/scripts/matrix/ there are 4 python scripts:

saveMatrix.py, oldSaveMatrix.py, loadMatrix.py, oldLoadMatrix.py

The saveMatrix.py and loadMatrix.py are for use with the current front end codes (which start counting from 1), where as the old*.py files are for the old system.

To use saveMatrix.py you need to specify the number of inputs, outputs, and the base name of the matrix (i.e. C1:LSP-DOF2PD_MTRX is the base of C1:LSP-DOF2PD_MTRX_0_0_GAIN for example), as well as an ouptut file where the values are stored.

So to save the BS in_matrix setting you could do (from /cvs/cds/caltech/scripts/matrix/)

./saveMatrix.py -i 4 -o 5 -n "C1:SUS-BS_TO_COIL_MTRX" -f -d ./to_coil_mtrx.txt

The -i 4 indicates 4 inputs, the -o 5 indicates 5 outputs, -n "blah blah" indicates the base channel name, -f indicates a matrix bank of filters (if its just a normal matrix with no filters, drop the -f flag), and -d ./to_coil_mtrx.txt indicates the destination file.

To write the matrix, you do virtually the same thing:

./loadMatrix.py -n "C1:SUS-PRM_TO_COIL_MTRX" -f -d ./to_coil_mtrx.txt

In this case, you're writing the saved values of the BS, to the PRM.  This method might be faster if you're trying to fill in a bunch of new matrices that are identical rather than typing 1's and -1's 20 times for each matrix.

I'll have Yuta add his how-to of this to the wiki.

While we looking using dtt and going over the basics of its operation, we discovered that the filter sample rates for the suspensions were still set to 2048 Hz, rather than 16384 Hz which is the new front end.  This caused the filters loaded into the front ends to not behave as expected.

After correcting the sample rate, the transfer functions obtained from dtt are now looking like the bode plots from foton.

We fixed the C1SUS.txt and C1MCS.txt files in the /opt/rtcds/caltech/c1/chans/ directory, by changing the SAMPLING lines to have 16384 rather than 2048.

I'm hoping to get a proper install this week done, but for now, this a stop gap.

To start diagnostic test tools, go to rosalba.  (Either sit at it, or ssh -X rosalba).

cd /opt/apps

type "bash", this starts a bash shell

source gds-env.bash

diaggui

 --------- Debugging section ------

If that throws up errors, try looking with "diag -i" and see if there's a line that starts with nds.  In the case last night, Alex had not setup a diagconf configuration file in the /etc/xinetd.d directory, which setups up the diagconf service under the xinit service.  To restart that service (if for example the nds line doesn't show up), go to /etc/init.d/ and type "sudo xinit start" (or restart).

Other problems can include awg and/or tpman not running for a particular model on the front end machine.  I.e. diag -i should show 3 results from 192.168.113.85 (c1x02, c1sus, c1mcs) at the moment , for both awg and tp.  If not, that means awg and tpman need to be restarted for those.

These can be started manually by going to the front end, to the /opt/rtcds/caltech/c1/target/gds/bin/ directory, and running awgtpman -s sysname (or in the case of IOP files [c1x02, c1x03, etc], awgtpman -s sysname -4.  Better is probably to run the start scripts which live /opt/rtcds/caltech/c1/scripts/ which kills and restarts all the process for you.

This is the link to the NDS2 webpage:

https://www.lsc-group.phys.uwm.edu/daswg/wiki/NetworkDataServer2

We should install this so that we can use this modern interface to get 40m data from outside and inside of the 40m.

YES ! We got the green light coming out from the OMC chamber to the PSL table !

 (Koji, Kiwamu, Yuta)

Background

As a result of the work in the chambers, the green beam reached the OMC chamber yesterday.
Today's mission was to let the green beam coming out from the chambers to the PSL table.

What we did:
1. Installed the last three steering mirrors.
  The mirrors were 532 HR mirror with AR and 1deg wedge (CVI Y2-LW-1-2050-UV-45-P/AR).
  Two of them are placed to the MC chamber. Another one was to the OMC chamber

During putting the mirrors to the MC chamber, we found that a cable tower was sitting on a position exactly where we wanted to put one of the mirrors.

So we moved the tower to the very south west corner. 

2. Installed a periscope to the MC chamber

The function of this periscope is to lower the beam height of the green light which is risen up by another periscope in the BS chamber.

We aligned it to the green beam, so that the beam hits the center of the mirrors on the periscope.  

3. Aligned the optics

We aligned the green mirrors so that we can let the green beam go out from the chamber.

Actually the inside of the OMC chamber didn't look like the same as that of our optical layout.

For example there is unknown base plate, which apparently disturbs the location of our last steering mirror.

Therefore we had to change the designed position of the steering mirror.

Now the mirror is sitting near the designed position (~ 1/2 inch off), but it's fine because it doesn't clip any 1064 beam.

 
Result:

The green beam is now hitting the north wall of the PSL table.

Notes:

The green beam looks having some fringes, it may be caused by a multiple reflection from a TT when the green beam goes through it. We are going to check it. 

Next work:

- Damping of the suspended optics

- Resurrect MC and its stable lock

- Remove MCT pickoff path

- Align optics in the main path

- Recycled Michelson lock

Today I checked the CCD cables which is connected to the VIDEOMUX.

17 cables are type of RG59, 8 cables are type of RG58. I have not figured out the type of other cables(23 cables) yet.

The reason I am checking the cables is for replacing the cables with impedance of 50 or 52 ohm by those with impedance of 75 ohm.

After I figures out which cable has not proper impedance, I will make new cables and substitute them in order to match the impedance, which would lead to better VIDEO signal.

To check the impedance of each CCD cable, I went to the VIDEOMUX and looked for the label on the cable's surface.

Type of RG59 is designated to the cable of impedance 75ohm. I wrote down each cable's input or output channel number with observation(whether it is of type RG59 or not).

The result of observation is as follows.

For 23 cables that I have not figured out their type, cables are too entangled so it is limited to look for the label along each cable.

I will try to figure out more tomorrow. Any suggestion would be really appreciated.

Kiwamu, Koji, Yutah, Rana, Jan and Steve

We removed the west access connector this afternoon.

We moved the filters for the mode cleaner optics over from the C1SUS.txt file in /opt/rtcds/caltech/c1/chans/ to the C1MCS.txt file, and placed SUS_ on the front of all the filter names.  This has let us load he filters for the mode cleaner optics.

At the moment, we cannot seem to get testpoints for the optics (i.e. dtt is not working, even the specially installed ones on rosalba). I've asked Yuta to enter in the correct matrix elements and turn the correct filters on, then save with a burt backup.

You can find the sitemap medm screen in

/opt/rtcds/caltech/c1/medm/master

The settings for the screens were last saved by burt in the original system on Sept 29, 2010 at 11:07.  So go to the

/cvs/cds/caltech/burt/autoburt/snapshots/2010/Sep/29/11:07

directory.  You can grep for the channels in the files in this directory.

You can also then use the autoBurt.req file in the /opt/rtcds/caltech/c1/target/sysname/sysnameepics (c1sus/c1susepics) to backup the settings entered.  Save to the /opt/rtcds/caltech/c1/target/snapshots directory for now.

Apparently when updating front end codes from rtlinux to the patched Gentoo, certain files don't get deleted when running make clean, such as the sysfe.rtl files in the advLigoRTS/src/fe/sys directories.  This fouls the start up scripts by making it think it should be configured for rtlinux rather than the Gentoo kernel module.

 I installed the package x264-devel on allegra.martian.  This package provides headers and libraries for the popular h264 video codec.  I am going to use this in the GStreamer streaming media server on Allegra.

Fb is now once again actually recording trends.

A section of the daqdrc file (located in /opt/rtcds/caltech/c1/target/fb/ directory) had been commented out by Alex and never uncommented.  This section included the commands which actually make the fb record trends.

The section now reads as:

# comment out this block to stop saving data

#
start frame-saver;
sync frame-saver;
start trender;
start trend-frame-saver;
sync trend-frame-saver;
start minute-trend-frame-saver;
sync minute-trend-frame-saver;
start raw_minute_trend_saver;
#start frame-writer "225.225.225.1" broadcast="131.215.113.0" all;
#sleep 5;

 With a help from Joe, I made a diagram of the simulated plant for green locking in order to get better understanding and consensus.

Eventually these simulated plants will help us developing (sometimes debugging) the digital control systems.

Here is the diagram which tells us how we will setup and link the control/plant models and on which machine they will be running.

Basically upper side represents the realtime control, and the lower side is the simulated plant.

The models are talking to each other via either a local shared memory (orange line) or the reflective memory network (purple line).

 Each model is stil not systematically named, at some point we have to have an absolute standard for naming the models.

- current model names -

  GCV = Green Control model at Vertex

  GCX(Y) = Green Control model at X (Y) end

  GPV = Green Plant model at Vertex

 - things to be done -

1. let the RFM work

2. revise the old plant models : SUP, SPX(Y) and LSP

Accelerometers xyz were moved from IOO-south/west  corner to under PSL table. They were turned off for ~20 minutes.

Guralp was also moved eastward about 2 ft. It is not leveled.

This is part of the preparation to remove access connector.

(Koji, Kiwamu, Yuta)

Lots of progress for the optics placement in the vacuum chamber.
We are ready to go to the next step: open the access connector between IMC and OMC. 

Background:

The actual work in the vacuum chamber started.
The first goal of the vent is to get the green beam coming out from the chambers to the PSL table.

What we did:

1. Inspection of the tip-tilt suspension

The alignments of the TTs were inspected. We had five TTs having been sitting on the table in Bob's clean room.
Prior to their installation we checked the alignments of those because they sometimes showed large hysteresis mainly in the pitch directions.

If a TT has the hysteresis, the pitch position doesn't come back to the previous position. This may cause an issue of the interferometer operation.

- SN001, SN003, SN005 looked well aligned and show no hysteresis.

- The alignment of SN002 was not so good (theta ~ 0.004 rad ) compared to those three, but no hysteresis, we think this guy is still acceptable for the installation.

- SN004 had an apparent hysteresis. This guy doesn't come back to the previous place, being applied a touch. We have to fix this at some point.

2. Work in the ITMX chamber

Now all of the optic in this chamber was installed in the approximate place.

- Installed POX/POP steering mirrors.

- TT(SN003) was placed.

- The two steering optics for ITMX OPLEV were placed at the designed positions.

3. Work in the BS chamber

Installed 2 TTs to the BS chamber.
- SR3: TT(SN001)
- PR3: TT(SN005)

After the alignment of the green steering mirrors, we confirmed
the green beam is successfully hitting the west wall of the OMC chamber.

Those TTs are approximately aligned using the weakly reflected green beams.

Next work:

- Open the access connector

- Place another periscope and two steering mirrors for green

- Damping of the suspended optics

- Resurrect MC and its stable lock

- Remove MCT pickoff path

- Align optics in the main path

- Recycled Michelson lock

I modified the dhcpd.conf file in /etc/dhcp on the fb machine.  I added a entry for c1ioo, listing its MAC address and ip number near the bottom of the file.  I then restarted the dhcp server using "sudo /etc/init.d/dhcpd restart" while on the fb machine.

I also modified the rtsystab, which is used to determine which front end codes start on boot up of a machine.  I added a line: c1ioo   c1x03  c1ioo

I am now in the process of getting c1ioo to come up as a Gentoo machine so I can build a model with an RFM connection in it and test the communication between c1sus and c1ioo.  This involves removing the hard drives and checking to make sure the boot priority is correct (i.e. it checks for a network boot).

 I uninstalled gstreamer-devel and gst-plugins-base-devel on Rosalba.  Here is the command I ran:

$ sudo yum remove gstreamer-devel gstreamer-plugins-base-devel

Actually, I had installed these myself a few days earlier, before I knew that I should be recording such changes in the elog.  I'm sorry!

I've updated the CDS wiki page listing the wiring of the 40m suspensions with the correct binary output channels.  I previously had confused the wiring of the Auxillary crate XY220 (watchdogs) with the SOS coil dewhitening bypasses.  So I had wound up with the wrong channels (the physical cables we plugged in were correct, just what I thought was going on channel X of that cable was wrong).  This has been corrected in the plan now.  The updated channel/cable list is at http://lhocds.ligo-wa.caltech.edu:8000/40m/Upgrade_09/CDS/Suspension_wiring_to_channels

Inside the FSS box, the FAST path has a ~10 Hz pole made up from the 15k resistor and the 1 uF cap before the output connector.

This should be moved over to the output of the driver to make the driver happy - without yet measuring the high frequency response,

it looks like to me that its becoming unhappy with the purely capacitive load of the NPRO's PZT. This will require a little surgery inside

the FSS box, but its probably justified now that we know the Thorlabs box isn't completely horrible.

 We measured the Thorlabs HV Driver's TF today. It is quite flat from 1k to 10k before going up to 25 dB at 100k,

and the response does not change with the DC offset input.

The driver is used for driving the NPRO's PZT which requires higher voltage than that of the previous setup.

We need to understand how the driver might effect the FSS loop TF, and we want to make sure that the driver

will have the same response with DC input offset.

Setup

We used SR785 to measure the TF. Source ch was split by a T, one connected to Driver's input, another one connected to the reference (ch A). See fig2.

The driver output was split by another T. One output was connected to NPRO,

another was connected to a 1nF capacitor in a Pomona box, as a high pass filer (for high voltage), then to the response (ch B)

 The source input is  DC offset by 2V which corresponds to 38 V DC offset on the driver's output.

The capacitance of the PZT on the NPRO is 2.36 nF, as measured by LC meter.

 The result shows that the driver's TF is flat from 1k to 10k, and goes up at higher frequency, see fig1.

The next step is trying to roll of the gain at high frequency for PZT. A capacitor connected to ground might be used to roll off the frequency of the driver's output.

We will inspect the TF at higher frequency (above 100 kHz) as well.

We realized we cannot build code with the current RCG compiler on c1ioo or c1iscex, since these are not Gentoo machines.  We need either to get a backwards compatible code generator, or change the boot priority (removing the harddrives also probably works) for c1ioo and c1iscex so they do the diskless Gentoo thing.  This would involve adding some MAC address to the framebuilder dhcpd.conf file in /etc/dhcp along with the computer IPs, and then modifying the /diskless/root/etc/rtsystab with the right machine names and models to start.

I also need to bring some of the older, neglected models up to current build standards. I.e. use cdsIPCx_RFM instead of cdsIPCx and so forth. 

Need to fix the binary outputs for c1sus/c1mcs.  Need to actually get the RFM running, since Kiwamu was having some issues with his green RFM test model.  We have the latest checkout from Rolf, but we have no proof that it actually works.

The c1sus model was split into 2, so that c1sus controls BS, PRM, SRM, ITMX, ITMY, while c1mcs controls MC1, MC2, MC3.  The c1mcs uses shared memory to tell c1sus what signals to the binary outputs (which control analog whitening/dewhitening filters), since two models can't control a binary output.

This split was done because the CPU time was running above 60 microseconds (the limit allowable since we're trying to run at 16kHz). Apparently the work Alex had done getting testpoints working had put a greater load on the cpu and pushed it over an acceptable maximum.    After removing the MC optics controls, the CPU time dropped to about 47 microseconds from about 67 microseconds.  The c1mcs is taking about 20 microseconds per cycle.

The new model is using the top_names functionality to still call the channels C1SUS-XXX_YYY.  However, the directory to find the actual medm filter modules is /opt/rtcds/caltech/c1/medm/c1mcs, and the gds testpoint screen for that model is called C1MCS-GDS_TP.adl.  I'm currently in the process of updating the medm screens to point to the correct location.

Also, while plugging in the cables from the coil dewhitening boards, we realized I (Joe) had made a mistake in the assignment of channels to the binary output boards.  I need to re-examine Jay's old drawings and fix the simulink model binary outputs.

Our visiting graduate student Yuta Michimura received 40m specific basic safety training today.

For some reason, the dhcp server running on the fb machine which assigns the IP address to c1sus (since its running a diskless boot) was down.  This was preventing c1sus from coming up properly.  The symptom was an error indicated no DHCP offers were made(when I plugged a keyboard and monitor in).

To check if the dhcp server is running, run ps -ef | grep dhcpd.  If its not, it can be started with "sudo /etc/init.d/dhcpd start"

1) Need to check 1 PPS signal alignment

2) Figure out why 1PPS and ADC/DAC testpoints went away from feCodeGen.pl?

3) Fix 1PPS testpoint giving NaN data

4) Figure out why is daqd printing "making gps time correction" twice?

5) Need to investigate why mx_streams are still getting stuck

6) Epics channels should not go out on 114 network (seen messages when doing
burt restore/save).

7) Dataviewer leaves test points hanging, daqd does not deallocate them
(net_Writer.c shutdown_netwriter call)

8) Need to install wiper scripts on fb

9) Need to install newer kernel on fb to avoid loading myrinet firmware
(avoid boot delay)

I've added a new directory in /opt/rtcds/caltech/c1/core called rts_simlink.  This directory is now in the 40m svn.  Unfortunately, the simlink files used to generate the front end c codes live in a directory controlled by the CDS svn.  So I've copied the .mdl files from /opt/rtcds/caltech/c1/core/advLigoRTS/src/epics/simLink/ into this new directory and added them into the 40m svn.  When making changes to the simlink files, please copy them to this new directory and check them in so we can a useful history of the models.

Alex is installing the newly compiled gds code (compiled on Centos 5.5 on Rosalba) which does in fact include the ezca type tools. 

At the moment we don't have a solaris compile, although that should be done at somepoint in the future.  It means the gds tools (diaggui, foton, etc) won't work on op440m.  On the bright side, this newer gds code has a foton that doesn't seem to crash all the time on Linux.

Alex fixed the time issue with the IRIG-B signal being far off, apparently their IRIG-B signal in downs seems to be different.  He simply corrected for the difference in the two signals in the code.

For debugging purposes we uncommented the following line in the feCodeGen.pl script (in /opt/rtcds/caltech/c1/advLigoRTS/src/epics/util/):

print EPICS "test_points ONE_PPS $dac_testpoint_names $::extraTestPoints\n" 

This is to make every ADC testpoint available from the IOP (such as c1x02).

Its pretty exciting to see that Joe got Alex to actually use the ELOG. Its a proof that even rare events occur if you are patient enough.

1) I fixed the MEDM links to point to the new sitemap.adl in /opt/rtcds. There is a link on the new sitemap which points to the old sitemap so that there is nothing destroyed yet.

2) Some of the fields in the screen are white. These are from the new c1sus processor, not issues with the slow controls. I think its just stuff that has not yet been created in the C1SUS simulink module.

3) The PZT steering controls are gone. Without this we cannot get the beam down the arm. Must fix before aliging things after the MC. Since PZT used to be controlled by ASC, we'll have to wire the Piezo Jena PZT controls in from a different VME 4116. Possibly c1iool0's crate?

4) Also, the IPANG and IPPOS are somehow not working right. I guess this is because they are part of the ASC / the old ETMX system. We'll have to wire the IPANG QPD into the new ETMY ADC system if we want to get the initial alignment into the Y-arm correct.

5) I've started migrating things over from the old SITEMAP. Please just use the new SITEMAP. it has a red link to the old one, but eventually everything on the new one will work after Joe, Alex, me, and Kiwamu are done tweaking.

(Kiwamu, Yuta)

Background:
 We wanted to make aldabella and mariabella know how to work.

What we did:
1. Added 2 lines to /etc/rc.local
 /sbin/modprobe ndiswrapper
 sleep 10
 mount linux1:/home/cds/ /cvs/cds

2. Edited ~/.cshrc
 source /cvs/cds/caltech/cshrc.40m

Result:
 Working environment is set to aldabella and mariabella. They have their access to the main system, linux1, now.

Note:
 fstab doesn't work for aldabella and mariabella because the mount should be done after ndiswrapper loads.

The frame builder is timed from the Symmetricom GPS card now, which is getting the IRIGB timecode from the freq. distribution amplifier (from the VME GPS receiver card).

I have adjusted the GPS seconds to match the real GPS time and the DTT seems to be happy: sweeping MC2 MCL filter module produces nice plot.

Test points are working on SUS.

Excitations are working on SUS.

I am leaving the frame builder running and acquiring the data.

Alex

There currently seems to be a timing issue with  the frame builder.  We switched over to using a symmetricom card to get an IRIG-B signal into the fb machine, but the gps time stamp is way off (~80 years Alex said).

If there is a frame buiilder issue, its currently often necessary to kill the associated mx_stream processes, since they don't seem to restart gracefully.  To fix it the following steps should be taken:

Kill frame builder, kill the two mx_stream processes, then /etc/restart_streams/, then restart the frame builder (usual daqd -c ./daqdrc >& ./daqd.log in /opt/rtcds/caltech/c1/target/fb).

To restart (or start after a boot) the nds server, you need to go to /opt/rtcds/caltech/c1/target/fb and type

./nds /opt/rtcds/caltech/c1/target/fb/pipe

At this time, testpoints are kind of working, but timing issues seem to be preventing useful work being done with it.  I'm leaving with Alex working on the code.

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

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

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

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

Result:
 aldabella now connects to the wireless martian network.

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

The control room's north west corner smelled like propane gas  yesterday around 16:30

We all agreed that the smell was real and I called the safety office. I was told that they received 6 other calls from different parts of the campus.

The smell disappeared in about a half an hour.

The centos 5.5 compiled gds code is currently living on rosalba in the /opt/app directory (this is local to Rosalba only).  It has not been fully compiled properly yet.  It is still missing ezcaread/write/ and so forth.  Once we have a fully working code, we'll propagate it to the correct directories on linux1.

So to have a working dtt session with the new front ends, log into rosalba, go to opt/apps/, and source gds-env.bash in /opt/apps (you need to be in bash for this to work, Alex has not made a tcsh environment script yet).  This will let get testpoints and be able to make transfer function measurements, for example

Also, to build the latest awgtpman, got to fb, go to /opt/rtcds/caltech/c1/core/advLigoRTS/src/gds, and type make.  This has been done and mentioned just as reference.

The awgtpman along with the front end models should startup automatically on reboot of c1sus (courtesy of the /etc/rc.local file).

 Atm1, Vertex crane controller unit on horizontal I-beam.

            Module CCES-407 1HP 2.3A 460V/3 phase on the right was replaced. Speed was increased  to 30 Hz

Atm2, See burned insulation on black wire that was shorting to the large suppressor resistor on Atm3 One can see the pit marks on the right end of it.

        This large power dissipater resistor got hot as the malfunctioning controller 407 broke down.   Touching black power wire insulation melted and made a short.

          So the heat was created and finally the fuses were blown. The unnecessary large fuses were replaced by small ones.

Fortunately we had one spare controller on hand that made this repair to be done fast.

We used the new Crane Safety Check list  from LIGO-E1000379-v1 the first time yesterday before doors were removed.

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

aldabella:
 Dell Inspiron E1505 laptop
 Broadcom Corporation BCM4311 802.11b/g WLAN (rev 01) (PCIID: 14e4:4311 (rev 01))

What I did:
1. I followed this method(Japanese!): http://www.linuxmania.jp/wireless_lan.html
 Except I installed ndiswrapper-1.56 and cabextracted sp32156.exe.
  http://sourceforge.net/apps/mediawiki/ndiswrapper/index.php?title=Broadcom_BCM4311
 Also, I didn't run
  # ndiswrapper -m

2. Then I did step #6 in here: http://nodus.ligo.caltech.edu:8080/40m/1275
 Note that the hardware is eth1 instead of wlan0.

3. Added the following line to /etc/rc.d/rc.local to make ndiswrapper load on every boot:
 /sbin/modprobe ndiswrapper

Result:
 aldabella now connects to the wireless martian network on every boot!!

Note:
 Somehow, the method that uses Broadcom official driver doesn't work.
  http://wiki.centos.org/HowTos/Laptops/Wireless/Broadcom
 It returns the following error when activating eth1:
  Error for wireless request "Set Encode" (8B2A) :
    SET failed on device eth1 ; Invalid argument.
  Error for wireless request "Set Encode" (8B2A) :
    SET failed on device eth1; Invalid argument.

(Steve, Koji, Joe, Kiwamu, Yuta)

Background:
 The vent was started on Monday, and finished on Tuesday.
 We were to open the doors on Tuesday, but we couldn't because the vertex crane got out of order.
 Now the crane was fixed, and so we opened the doors today.

What we did:
 We opened the north side of the BS chamber and the west side of the ITMX chamber.
 Now, the light doors are put instead.