Two SOS suspensions for the ETMs were disassembled and packed for cleaning and baking by Bob.

These suspensions have been stored on the X end flow bench long years, and looked quite old.

They have some differences to the modern SOSs.

- The top suspension block is made of aluminum and had dog clamps to fix the wires.
- The side bars are not symmetric: the side OSEM can only be fixed at the right bar (left side in the picture).
- EQ stops were made of Viton.
- One of the tower bases seems to have finger prints (of Mike Zucker?).

I found that the OSEM plates had no play. We know that the arrangement of the OSEMs gets quite difficult
in this situation. Therefore the holes of the screws were drilled with the larger drill.

We decided to replace all of the screws to the new ones as all of the screws are Ag plated and got corroded
by silver sulfide (Ag₂S). I checked our stock in the clean room. We have enough screws.

Important note: Use stainless screws in aluminum / Silver-plated screws in stainless
There exists some study about galling: LIGO-G020394-00-D

The day before yesterday, I was cleaning a flow bench in the clean room.

I found that one SOS was standing there. It is the SRM suspension.

I thought of the nice idea:

- The installed PRM is actually the SRM (SRMU04). It is 2nd best SRM but not so diiferent form the best one.
==> Use this as the final SRM

- The SRM tower at the clean room
==> Use this as the final PRM tower.
==> The mirror (SRMU03) will be stored in a cabinet.

- The two SOS towers will be baked soon
==> Use them for the ETMs

This reduces the unnecessary maneuver of the suspension towers.

In doing a re-inventory prior to the IOO chassis installation, I re-discovered we had a missing interface board that goes in an IO chassis.  This board connects the chassis to the computer and lets them talk to each other.  After going to Downs we remembered Alex had taken a possibly broken interface board back to downs for testing. 

Apparently the results of that testing was it was broken.  This was about 2.5 months ago and unfortunately it hadn't been sent back for repairs or a replacement ordered.  Its my fault for not following up on that sooner.

I asked Rolf what the plan for the broken one was.  His response was  they were planning on repairing it, and that he'd have it sent back for repairs today.  My guess the turn around time for that is on the order of 3-4 weeks (based on conversations with Gary), however it could be longer.  This will affect when the last IO chassis (LSC) can be made fully functional.  I did however pickup the 100 foot fiber cable for going between the LSC chassis and the LSC computer (which will be located in 1X3).

As a general piece of information, according to Gary the latest part number for these cards is OSS-SHB-ELB-x4/x8-2.0 and they cost 936 dollars (latest quote).

I took the 5565 RFM card out of the IOVME machine to so I could put it in the new IO chassis that will be replacing it.  It is no longer on the RFM network.  This doesn't affect the slow channels associated with the auxilliary crate.

Cleaned up cables on the top and bottom. Vacuumed both areas. We still have some remaining shading from the MOPA umbilical and more unknown BNC cables hanging around.

I installed the blue IP camera from ZoneNet onto the PSL table. It gets its power from the overhead socket and connects via Cat5 to the Netgear switch in the PSL/IO rack.

You can connect to it on the Martian network by connecting to http://192.168.113.201:3037. Your computer must have Java working in the browser to make that work.

So far, this works on rossa, but not the other machines. It will take someone with Joe/Kiwamu level linux savvy to fix the java on there. I also don't know how to fix the host tables, so someone please add this camera to the list and give it a name.

As you can see from the image, it is  illuminating the PSL with IR LEDs. I've sent an email to the tech support to find out if we can disable the LEDs.

Our new 2W Mephisto has a pretty zippy "SLOW" temperature input. Tuning the perl PID servo, I found that the best response came from setting

the "P" and "D" terms to zero. This is because the internal temperature stabilization servo has a fairly high UGF. In the attached

image you can see how the open loop step response looks (loop is open then the "KI" parameter is set to zero). The internal servo

really has too little damping. There is a 30% overshoot when it gets a temperature step. For this kind of servo Innolight would have done better

to back off on the gain until they got back some phase margin.

New SLOW parameters:

timestep = 1.9 s

KP = 0

KI = 0.035

KD = 0

Larry stopped by today and had to disconnect the m25 machine (this is the 1st GC machine on the left as you walk into the control room) because its IP was conflicting with a machine over in Downs.  Do not use 131.215.115.125 as the IP on this machine as this is already assigned to someone else.  They couldn't figure out the root password to change it which is why it is not currently plugged into the network, and is not to be until an appropriate IP is assigned.

They've asked that whoever set the machine up to please contact them (extension 2974).

I talked to with Alex this morning, discussing what he needed to do to have a frame builder running that was compatible with the new front ends.

1) We need a heavy duty router as a separate network dedicated to data acquisition running between the front ends and the frame builder.  Alex says they have one over at downs, although a new one may need to be ordered to replace that one.

2) The frame builder is a linux machine (basically we stop using the Sun fb40m and start using the linux fb40m2 directly.).

3) He is currently working on the code today.  Depending on progress today, it might be installable tomorrow.

[Rana, Koji, Joe]

We pulled the phase shifters in the 1X2 rack out to make room for megatron.  Megatron will be converted into c1ioo, and the 8 core, 1U computer will be used as c1lsc.  A temporary ethernet cable was run from 1X2 to 1X3 to connect megatron to the same sub-network.

The c1lsc machine was worked on today, setting it up to run the real time code, along with the correct controls accounts, passwords, .cshrc files, etc.  It needs to be moved from 1X1 to 1X4 tomorrow.

The PSL out  2" OD beam guide tube was cut  1.5" shorter to 13.5"

The 10" OD  0.25" wall Al tube was replaced by a  lighter, not anodized and thinner  wall 0.094" tube of 15.5" lenght, that is 0.75" shorter.

The new position of the PSL table made these cuts necessary.

John Miller has arrived from Australia with 3 bags of  Wagonga Coffee. Trade bargaining has started on

250 mgs of Sumatran Mandehling, Timur and Papua New Guine.

I've made a first pass at a rack diagram for the 1X1 and 1X2 racks, attached as png.

Gray is old existing boards, power supplies etc.  Blue is new CDS computers and IO chassis, and gold is for the Alberto's new RF electronics.  I still need to double check on whether some of these boards will be coming out (perhaps the 2U FSS ref board?).

[Aidan, Tara, Joe]

We pulled out what used to be the LSC/ASC fiber from the 1Y3 arm rack, and then redirected it to the 1X1 rack.  This will be used as the c1ioo 1PPS timing signal.  So c1ioo is using the old c1iovme fiber for RFM communications back to the bypass switch, and the old LSC fiber for 1PPS.

The c1sus machine will be using the former sosvme fiber for communications to the RFM bypass switch.  It already had a 1 PPS timing fiber.

The c1iscex machine had a new timing fiber already put in, and will be using the c1iscey vme crate's RFM for communication.

We still need to pull up the extra blue fiber which was used to connect c1iscex directly to c1sus, and reuse it as the 1PPS signal to the new front end on the Y arm. 

Alex has said he'll come in tomorrow morning to install the new FB code.

Net switch mumbo-jumbo:

Although Rana is going to buy a replacement for the Netgear Switch for martian, I opened the lid of the Netgear as the fan already have stopped working.
Also the lid of the other network switch for GC (Black one) was opened as it has a broken fan and a noisy half-broken fan.

I have asked Steve to buy replacement fans. These would also be the replacement of the replacement.

During the work, it seemed that I accidentally toggled the power supply of linux1. It lead lengthy fsck of the storage.
This is why all of the machines which rely on linux1 got freezed. linux1 is back and the machines looked happy now.

If you find any machine disconnected from the network, please consult with me.

I tested the new table top frequency stabilization system(TTFSS),
I haven’t finished it yet, and accidentally fried one amplifier in the circuit.

We received three sets of a new TTFSS system which will replace the current FSS.
It needs to be checked that the system works as specified before we can use it.

- Result

I followed the instruction written on E10000405-v1
The first test inspected how much the currents were drawn from the +/- 24 V power supply.
+24 V drew 350 mA and -24 V drew 160 mA as shown on pwr supply’s current monitor.
They exceeded the specified value which was 200 +/- 20 mA, but nothing went wrong during the test.
Nothing got overheated, all voltage outputs were correct so I proceeded.
I have gone down the list to 6, and everything works as specified.

- Correcting the document for the test procedure

I found a few errors on the instruction document. I’ll notify the author tomorrow.

- How GVA-81 amplifier on D0901894 rev A got fried

During the test, I used a mirror on a stick that looked like a dental tool to see under the board.
Unfortunately, the steel edge touched a board and caused a spark. The voltage on -24 dropped to -16.
I think this happened because the pwr supply tried to decrease the current from shorted circuit,
as I shorted it only short time ( a blink of an eye), it could not reduce the voltage to zero.
When I was checking the power supply and about to adjust the voltage back to the right value
(about 4-5 seconds after the spark,) smoke came out of the circuit.

Koji investigated the circuit and found that a GVA 81 amplifier was broken.

This was checked by applying 5V to the amp, and slightly increasing the current.
The voltage dropped to zero as the amp was broken, so its circuit was shorted.

I’ll see if I can replace this at EE lab at Downs.
If I cannot find a spare one, I’ll replace it with a resistor and resume the test procedure.
Because it amplifies LO signal, which won’t be used during the test.

Zach> Nodus seemed to be working fine again, and I was browsing the elog with no
Zach> problem. I tried making an entry, but when I started uploading a file it
Zach> became unresponsive. Tried SSHing, but I get no prompt after the welcome
Zach> blurb. ^C gives me some kind of tcsh prompt (">"), which only really
Zach> responds to ^D (logout). Don't know what else to do, but I assume someone
Zach> knows what's going on.

By gracefully rebooting nodus, the problem was solved.

It (">") actually was the tcsh prompt, but any commands with the shared or dynamic link libraries looked unfunctional.

I could use
    cd /.../...
and
    echo *
to browse the directory tree. The main mounted file systems like /, /usr, /var, /cvs/cds/caltech looked fine.
I was afraid that the important library files were damaged.

I tried
    umountall
and
    mountall
in order to flush the file systems.
These should run even without the libraries as mount must properly work even before /usr is mounted.

They indeed did something to the system. Once I re-launch a new login shell, the prompt was still ">"
but now I could use most of the commands.

I have rebooted by usual sudo-ing and now the services on nodus are back to the functional state again.

# nodus was working in the evening at around 9pm. I even made an e-log entry about that.
# So I like to assume this is not directly related to the linux1 incident. Something else could have happened.

SVN down

mafalda down

I am guessing that the NFS file system hangup may have caused some machines to get into an awkward state. We may be best off doing a controlled power cycle of everything...

svn is back after starting apache on nodus.

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

Alex came over this morning and we began work on the frame builder change over.  This required fb40m be brought down and disconnected from the RAID array, so the frame builder is not available.

He brought a Netgear switch which we've installed at the top of the 1X7 rack.  This will eventually be connected, via Cat 6 cable, to all the front ends.  It is connected to the new fb machine via a 10G fiber.

Alex has gone back to Downs to pickup a Symmetricon (sp?) card for getting timing information into the frame builder.  He will also be bringing back a harddrive with the necessary framebuilder software to be copied onto the new fb machine.

He said he'd like to also put a Gentoo boot server on the machine.  This boot server will not affect anything at the moment, but its apparently the style the sites are moving towards.  So you have a single boot server, and diskless front end computers, running Gentoo.  However for the moment we are sticking with our current Centos real time kernel (which is still compatible with the new frame builder code).  However this would make a switch over to the new system possible in the future.

At the moment, the RAID array is doing a file system check, and is going slowly while it checks terabytes of data.  We will continue work after lunch. 

 Punchline: things still don't work.

mafalda is up now.

I found that the cable for mafalda (the sole red cable) had a broken latch.
The cable was about falling off from the switch. As a first-aid, I used this technique to put a new latch, and put it into the switch.

Now I can logged in it. I did not rebooted it.

Big Johnny and I hacked a function generator output into the cross-connect of the 80 MHz VCO driver so that we could modulate the

amplitude of the light going into the RefCav. The goal of this is to measure the coefficient between cavity power fluctuations and the

apparent length fluctuations. This is to see if the thermo-optic noise in coatings behaves like we expect.

To do this we disconnected the wire #2 (white wire) at the cross-connect for the 9-pin D-sub which powers the VCO driver. This is

called VCOMODLEVEL (on the schematic and the screen). In the box, this modulates the gain in the homemade high power Amp which

sends the actual VCO signal to the AOM.

This signal is filtered inside the box by 2 poles at 34 Hz. I injected a sine wave of 3 Vpp into this input. The mean value was 4.6 V. The

RCTRANSPD = 0.83 Vdc. We measure a a peak there of 1.5 mVrms. To measure the frequency peak we look in

the FSS_FAST signal from the VME interface card. With a 10 mHz linewidth, there's no peak in the data above the background. This signal

is basically a direct measure of the signal going to the NPRO PZT, so the calibration is 1.1 MHz/V.

We expect a coefficient of ~20 Hz/uW (input power fluctuations). We have ~1 mW into the RC, so we might expect a ~20 Hz frequency shift.

That would be a peak-height of 20 uV. In fact, we get an upper limit of 10 uV.

 Later, with more averaging, we get an upper limit of 1e-3 V/V which translates to 1e-3 * 1.1 MHz / 1 mW ~ 1 Hz/uW. This is substantially lower

than the numbers in most of the frequency stabilization papers. Perhaps, this cavity has a very low absorption?

We found that a transistor was broken from yesterday spark too. We partially fixed TTFSS, and it should be enough for  testing purpose.

From yesterday test, we found that the RF amplifier for LO signal was broken. There was no spare at the electronic shop at Downs,

so we shorted the circuit for now.  Another part which was broken too was a transistor, Q3 PZT2222A, on D0901846.

It was removed and two connections, which are for Q3's 1 and 3 legs, are shorted. Now the voltages out from the regulators are back to normal.

We are checking a MAX333A switch, U6A on D0901894. it seems that the voltage that controls the switch disappears.

There might be a bad connection somewhere. This will be investigated next.

The squeezing open frame rack was moved from the south side of the PSL enclosure to the north side of the SP table.

AC power breaker is PC-2  #1

To startup medm screens for the new suspension front end, do the following:

1) From a control room machine, log into megatron

ssh -X megatron

2) Move to the new medm directory, and more specifically the master sub-directory

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

3) Run the basic sitemap in that directory

medm -x sitemap.adl

The new matrix of filters replacing the old ULPOS, URPOS, etc type filters is now on the screens.  This was previously hidden.  I also added the sensor input matrix entry for the side sensor.

Lastly, the C1SUS.txt filter bank was updated to place the old ULPOS type filters into the correct matrix filter bank.

The suspension controls still need all the correct values entered into the matrix entries (along with gains for the matrix of filter banks), as well as the filters turned on.  I hope to have some time tomorrow morning to do this, which basically involves looking at the old screens copying the values over.  The watch dogs are still controlled by the old control screens.  This will be fixed on Monday when I finish switching the front ends over from their sub-network to the main network, at which point logging into megatron will no longer be necessary.

  Q3, a PZT2222A transistor, on D0901846 is replaced by a GE-82. However, the board is still not fully function.

Since Q3, PZT2222A, was broken, I went to Wilson house and got some SP3904's for replacement. But somehow, I broke it during

installation, and did not notice it, and resumed the test. When I got to test 8 on the list, the TTFSS did not work as specified.

Koji checked and found out that -15V, Nref, Vref voltages output did not work correctly. So the SP3904 I installed was removed

and replaced with another SP3904 by Koji, and Vref is working. 

Q4 transistor is broken as well and it was replaced by GE 82.

Q1 might be broken too since -15V out is not working.

I'll go to Wilson house to get more transistors next week.

After the broken parts have been replaced, I have to make sure that I separate the power supply board from the rest of the circuit and

check if all V outputs are  working, then reconnect the board and check if the current input is reasonable before resume the test.

I hope the wrong input voltage problem today wouldn't damage anything else.

How much current do you need for each voltages?

GE-82 was the only PNP transister I could find in the lab. It's too old but we just like to confirm any other components are still functioning.

Similarly, we can confirm the functionality of the other components by skipping those current boost transisters,
if we don't need more than 30mA.

Issues I notice on first glance:

1. The OSEM Sensor Input matrix and the DOF2COIL Output matrix screens should be their own screens and linked from the overview. Right now they are not. Where is the input matrix?
2. The SIDE GAIN looks like zero on the main screen, but the side OSEM signal seems to be getting through to the SIDE filter bank. . I think the wiring of the SIDE signal through the input matrix is bogus.
3. The OUTPUT matrix seems to be the transpose of the previous OUTPUT matrix and we have lost the wires that connect the inputs and outputs to the matrix. We ought to think about how best to represent things on the OVERVIEW screen; probably only need to have a minimal representation and allow power users to open up the detailed screen.
4. The TIME string is whited out. How will this be done? Does each FE display its local time on its EPICS screens?
5. So far unable to get any channels on DV. How do we look at channels / test points?
6. As far as we can tell, there is no connection between the output of the SUSPOS, etc. filter banks and the OUTPUT MATRIX. So....nothing actually goes to the coil driver. Its hard to imagine that this new SUS could have ever worked. Is there any evidence that the damping actually worked in the past, or was it something like "well, the watchdog values came down to small numbers eventually..." ???
7. We are trying to debug the simulink file, but....the wiki entry on how to do this is out of date (yet updated as recently as August!) some path stuff just probably needs to be edited.

Basically the suspensions are not functioning yet and we can't attempt locking of the MC.

We added the Thorlabs HV Driver in between the FSS and the NPRO today. The FSS is locking with it, but we haven't taken any loop gain measurements.

This box takes 0-10 V and puts out 0-150 V. I set up the FSS SLOW loop so that it now servos the output of FAST ot be at +5V instead of 0V. This is an OK

temporary solution. In the future, we should add an offset into the output of the FSS board so that the natural output is 0-10 V.

I am suspicious that the Thorlabs box has not got enough zip to give us a nice crossover and so we should make sure to measure its frequency response with a capacitive load.

Blocked PSL output beam  into IFO

Checked: HV at IOO & OMC are off, jam nuts in position,

Closed V1 and VM3, opened VV1 to N2 regulator

We are venting at 1 Torr/min rate

The medm screens have been updated further, with the hidden matrices added in bright colors.  An example screen shot is attached.

Megatron has been renamed c1ioo and moved to martian network.  Similarly, c1sus and c1iscex are also on the martian network.  Medm screens can be run on any of the control machines and they will work.

Currently the suspension controller is running on c1sus.

The frame builder is currently running on the fb machine *however* it is not working well.  Test points and daq channels on the new front ends tended to crash it when Alex started the mx_stream to the fb via our new DAQ network (192.168.114.XXX, accessible through the front ends or fb - has a dedicated 1 gigabit network with up to 10 gigabit for the fb).  So for the moment, we're running without front end data. Alex will be back tomorrow to work on it. 

Alex claimed to have left the frame builder in a state where it should be recording slow data, however, I can't seem to access recent trends (i.e. since we started it today).  The frame builder throws up an error "Couldn't open raw minute trend file '/frames/trend/minute_raw/C1:Vac-P1_pressure', for example.  Realtime seems to work for slow channels however.  Remember to connect to fb, not fb40m. So it seems the fb is still in a mostly non-functional state.

Alex also started a job to convert all the old trends to the correct new data format, which should finish by tomorrow.

RA: Nice screen work. The old screens had a 'slow' slider effect when ramping the bias so that we couldn't whack the optic too hard. Is the new one instantaneous?

 took two runs of the script as usual

(Koji, Yuta, Kiwamu)

Now the pressure at P1 is 740 torr, which is close to the atmospheric pressure of 760 torr.

We changed the air cylinder twice in this evening, and the last cylinder ran out at about 23:00 pm.

We left it as it is. Steve is going to make a final touch for it tomorrow morning.

 Looking at the sliders, I apparently still need to connect them properly.  There's a mismatch between the medm screen channel name and the model name.  At the moment there is no "slow" slider effect implemented, so they are effectively instantaneous.  Talking with Alex, he suggests writing a little c-code block and adding it to the model.  I can use the c code used in the filter module ramps as a starting point.

The vertex crane drive is overheating, it stopped functioning. Service man will be here tomorrow morning.

I crane was just turned  on for for may be  about 5 minutes. The vertical drive was fine for a while, but the horizontal did not worked at all.

The crane is tagged out again and the controller box is cooling down.

We found a small PCB defect which is an excess copper shorting circuit on the daughter board,

it was removed and the signal on mixer monitor path is working properly.

 We were checking the new TTFSS upto test 10a on the instruction, E1000405 -V1. There was no signal at MIXER mon channel.

It turned out that U3 OpAmp on the daughter board, D040424, was not working because the circuit path for leg 15 was shorted

because of the board's defect. We can see from fig1 that the contact for the OpAmp's leg (2nd from left) touches ground.

We used a knife to scrap it out, see fig 2, and now this part is working properly.

I found that several linux libraries have been moved around and disabled today. In particular, I see a bunch of new stuff in apps/linux/ and ezca tools are not working.

Who did this and why is there no ELOG ???

Also found that someone has pulled the power cable to the function generator I was using to set the VCO offset. This is the one on top of the Rb clocks. Why?? Why no elog? This is again a big waste of time.

After asking Alex specifically what he did yesterday after I left, he indicated he copied  a bunch of stuff from Hanford, including the latest gds, fftw, libframe, root.  We also now have the new dtt code as well.  But those apparently were for the Gentoo build   After asking Alex about the ezca tools this morning, he discovered they weren't complied in the gds code he brought over.  We are in the process of getting the source over here and compiling the ezca tools. 

Alex is indicating to me that the currently compiled new gds code may not run on the Centos 5.5 since it was compiled Gentoo (which is what our new fb is running and apparently what they're using for the front ends at Hanford).  We may need to recompile the source on our local Centos 5.5 control machines to get some working gds code.  We're in the process of transferring the source code from Hanford.  Apparently this latest code is not in SVN yet, because at some point he needs to merge it with some other work other people have been doing in parallel and he hasn't had the time yet to do the work necessary for the merge.

For the moment, Alex is undoing the soft link changes he did pointing gds at the latest gds code he copied, and pointing back at the original install we had.

This is being recorded for posterity so we know where to look for the old controls settings.

The last good burt restore that was saved before turning off scipe25 aka c1dcuepics was on September 29, 11:07.

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

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.

 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.

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

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.

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.

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.

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

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