Some questions came arise to me:

A. How the green injection system should be? How the handing off between 532 and 1064 should be?

This is not new, though. It would be worth reminding.

B. Do we still need PMC if we use 2W innolight?

Innolight has low intensity noise at the detection freq. Also the spacial mode is clean.

C. Do we still need frequency prestabilization by RC?

Is the stabilization of the laser freq by the MC not enough?
What is the relationship with the green?

I pushed the "closed loop" button on PZT2 YAW around 3:40 pm today, then roughly recentered it using the DC Offset knob on the PiezoJena controller and the IP ANG QPD readbacks.  There was a large DC shift.    We'll watch and see how much it drifts in this state.

 Here's the trend.

The transient at ~22:40 is Rob switching to 'Open Loop' on the Piezo Jena PZTs. I don't see any qualitative change in the drift after this event.

At 05:55 UTC, I removed an iris that was blocking the IP POS beam (the sum goes up from 2 to 6.5) without disturbing the mirrors who's oplev beam are on that table. Steve has conceded one sugar Napoleon after betting against my ninja-like iris skills.

We should recenter the beam on IP POS now that its unclipped - I'll let it sit this way overnight just to get more drift data.

Inspecting the AS table to make an inventory of the photodiodes in use around the interferometer, I found a mysterious photodetector hiding behind PD1 (AS166).

It turned out the detector was an old type of QPD from the Squeezing Experiment a few years ago.

We removed the box and the cable to which it was connected from the table. We stored it in the optics cabinet along the X arm.

I wanted to see how long our IP POS beam has been badly clipped - turns out its since April 1, 2007.

Steve's April Fool's joke is chronicled then. The attached trend shows that the drop in IP POS is coincident with that event.

In trying to align IPPOS, I noticed that someone has placed a ND2.0 filter (factor of 100 attenuation) in front of it. This is kind of a waste - I have removed IPPOS to fix its resistors and avoid this bad optic. Also the beam coming onto the table is too big for the 1" diameter optics being used; we need to replace it with a 2" diamter optic (Y1-2037-45P).

IP ANG dropped by a factor of 2 back in early August of '08.

We need this guy on the investigation:

Its back in and re-centered. Our next move on IPPOS should be to replace its steering mirror with something bigger and more rigid.

Electronics changes:

20K -> 3.65 K  (R6, R20, R42, R31) (unused)

20K -> 3.65 K  (R7, R21, R32, R43, R11, R24, R35, R46)

If you look in the schematic (D990272), you see that its an AD797 transimpedance stage with a couple of LT1125 stages set to give some switchable gain. It looks like some of these

switches are on and some are not, but I am not sure where it would be controlled from. I've attached a snapshot of one quadrant of the schematic below.

The schematic shows the switches in the so-called 'normally closed' configuration. This is what the switches do with zero volts applied to the control inputs. As the schematic also shows,

just disconnecting the 'switch' inputs cause the switch's control inputs to go high (normally open configuration, i.e. pins 2-3 connected, pin4 open). For the record, the default positions of the IPPOS switches are:

switch1   high

switch2   low

switch3   low

switch4   high

** EDIT (Nov 2, 2009): I forgot to attach the before and after images; here they are:

I tried to compare the IP_POS time series with the IPANG and MC_TRANS but was foiled at first:

1) The IPANG scan rate was set to 0.5 second, so it doesn't resolve the pendulum motions well. Fixed in the .db file.

2) Someone had used a Windows/DOS editor to edit the .db file and it was filled with "^M" characters. I have removed them all using this command:   tr -d "\r" <ETMXaux.db > new.db

3) The MC_TRANS P/Y channels were on the MC Lock screen but had never been added to the DAQ. Remember, if there's a useful readback on an EPICS screen. its not necessarily in the frames unless you add it to the C0EDCU file. I have done that now and restarted the fb daqd. Channels now exist.

4) Changed the PREC of the IPPOS channels to 3 from 2.

5) changed the sign for the IBQPD (aka IPANG) so that bigger signal is positive on the EPICS screen.

The 33MHz mod depth is now controlled by the OMC (C1:OMC-SPARE_DAC_CH_15).  The setting to give us the same modulation depth as before is 14000 (in the offset field).

In this morning, we have disconnected SR785 which was in front of 1X2 rack, to measure a Hall sensor noise.

After a while, we put back SR785 and re-connected as it has been.

But the display setup might have been changed a little bit.

Does anyone know what the channels plugged in to the PEM ADCU, channels 5,6,7,8 are?  They aren't listed in the C1ADCU_PEM.ini file which tells the channel list/dataviewer/everything about all the rest of the signals which are plugged into that ADCU, so I'm not sure if they are used at all, or if they're holdovers from some previous time.  The cables are not labeled in a way that makes clear what they are.  Thanks!

I removed the multiply resonant EOM that has been set by a SURF student from PSL table.

I will use it for checking the resonant circuit.

For the CDS upgrade preparation I put and moved those stuff at the rack 1Y9:

Placed 1Y9-12 ADC to DB44/37 Adapter LIGO D080397

Placed 1Y9-14 DAC to IDC Adapter LIGO D080303

Moved the ethernet switch from 1Y9-16 to 1Y9-24

Wiki has also been updated.

In investigating why megatron wouldn't talk to the network, I re-discovered the fact that it had been placed on its own private network to avoid conflicts with the 40m's test point manager.  So I moved the linksys router (model WRT310N V2) down to 1Y9, plugged megatron into a normal network port, and connected its internet port to the rest of the gigabit network. 

Unfortunately, megatron still didn't see the rest of the network, and vice-versa.  I brought out my laptop and started looking at the settings.  It had been configured with the DMZ zone on for 192.168.1.2, which was Megatron's IP, so communications should flow through the router. Turns out it needs the dhcp server on the gateway router (131.215.113.2) to be on for everyone to talk to each other.  However, this may not be the best practice.  It'd probably be better to set the router IP to be fixed, and turn off the dhcp server on the gateway.  I'll look into doing this tomorrow.

Also during this I found the DNS server running on linux1 had its IP to name and name to IP files in disagreement on what the IP of megatron should be.  The IP to name claimed 131.215.113.95 while the name to IP claimed 131.215.113.178.  I set it so both said 131.215.113.178.  (These are in /var/named/chroot/var/ directory on linux1, the files are 113.215.131.in-addr.arpa.zone  and martian.zone - I modified the 113.215.131.in-addr.arpa.zone file).  This is the dhcp served IP address from the gateway, and in principle could change or be given to another machine while the dhcp server is on.

The elog just crashed and I rebooted it

I took the RFM 5565 card dropped off by Jay and installed it into megatron.  It is not very secure, as it was too tall for the slot and could not be locked down.  I did not connect the RFM fibers at this point, so just the card is plugged in.

Unfortunately, on power up, and immediately after the splash screen I get "NMI EVENT!" and "System halted due to fatal NMI". 

The status light on the RFM light remains a steady red as well.  There is a distinct possibility the card is broken in some way.

The card is a VMIPMC-5565 (which is the same as the card used by the ETMY front end machine).  We should get Alex to come in and look at it on Monday, but we may need to get a replacement.

The MC2 watchdogs tripped. I just restored them.

I also had to relock the MZ and then the Mode Cleaner.

I turned the auxialiary NPRO for the AbsL Experiment on. Its shutter stays closed.

This afternoon, while I was trying to add the StochMon channels to the frames, I rebooted the c1ioovme and c1iool0.

I had to do it twice because of a mispelling in the C1IOO.INI file that the first time prevented the computer to restart properly.

Eventually I restored the old .ini file, as it was before the changes.

After rebooting I also burtrestored.

During the process the mode cleaner got unlocked. Later on the autoclokcer couldn't engage. I had to run the MC_down and MC_up scripts.

We started the test of the new CDS system at ETMY.

The plan is as follows:
We do the ETMY test from 9:30 to 15:00 at ETMY from Nov 12~17. This disables the ETMY during this period.
From 15:00 of the each day, we restore the ETMY configuration and confirm the ETMY work properly.

Today we connected megatron to the existing AA/AI modules via designated I/F boxes. The status of the test was already reported by the other entry.

During the test, c1iscey was kept running. We disabled the ETMY actuation by WatchDog. We did not touch the RFM network.

After the test we disconnected our cables and restored the connection to ICS110B and the AI/AA boards.

The WatchDog switches were released.

The lock of the ETMY was confirmed. The full interferometer was aligned one by one. Left in the full configuration with LA=off.

I've changed megatron's controls account default shell to tcsh (like it was before).  It now sources cshrc.40m in /cvs/cds/caltech/ correctly at login, so all the usual aliases and programs work without doing any extra work.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2) Restarted the realtime code.

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

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

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

Koji, Rana

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

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

The ETMY was restored to the usual configuration.

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

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

The DAC channnel swapping was the last key!

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

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

This starts the FB.

Now the dataviewer and DTT work!

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

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

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

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

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

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

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

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

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

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

So be aware that:

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

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

I have to go through the problem...

The elog is up again.

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

/home/controls/cds/rts/

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

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

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

0x108000 (from suscomms )

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

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

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

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

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

-----------

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

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

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

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

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

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

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

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

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

[Sanjit, Jenne, Rob, Joe]

We added and tested the following channels from "/cvs/cds/gds/param/tpchn_C3.par" to "/cvs/cds/caltech/chans/daq/C1ASS.ini" appending a "_2048" extension to the channel name (as the name of a channel in .ini and .par files must be different):

[C1:ASS-TOP_CORR_IN1_2048]
[C1:ASS-TOP_ERR_EMPH_IN1_2048]
[C1:ASS-TOP_PEM_10_IN1_2048]
[C1:ASS-TOP_PEM_11_IN1_2048]
[C1:ASS-TOP_PEM_12_IN1_2048]
[C1:ASS-TOP_PEM_15_IN1_2048]
[C1:ASS-TOP_PEM_16_IN1_2048]
[C1:ASS-TOP_PEM_17_IN1_2048]
[C1:ASS-TOP_PEM_18_IN1_2048]
[C1:ASS-TOP_PEM_19_IN1_2048]
[C1:ASS-TOP_PEM_20_IN1_2048]
[C1:ASS-TOP_PEM_24_IN1_2048]
[C1:ASS-TOP_PEM_2_IN1_2048]
[C1:ASS-TOP_PEM_3_IN1_2048]
[C1:ASS-TOP_PEM_4_IN1_2048]
 

These five-line entries for each channels in the .par file were manually copy pasted from the .ini file, should think about a smarter way...

The old .par file is kept as: /cvs/cds/caltech/chans/daq/C1ASS.ini.20Nov2009

The current one is also saved as: /cvs/cds/caltech/chans/daq/C1ASS.ini.24Nov2009

And, the current one is committed to the svn.

NOTE: In the first attempt, the channel names were mistakenly kept the same in both the .ini and .par files and this caused DAQ daemon to crash badly. It could only be recovered by hard reboot of the frame builder.  Important info here: Jenne's elog 2316

I temporarily disconnected the Heliax cable that brings the 166MHz LO to the LSC rack.

I'm doing a couple of measurement and I'll put it back in as soon as I'm done.

I replaced the SMA end connector for the 166 MHZ Local Oscillator signal that goes to the back of the flange in the 1Y2 rack. The connector had got damaged after it twisted when I was tigheting the N connector of the Heliax cable on the front panel.

 These are the losses I measured on a RG-174 cable for the two frequencies that we're planning to use in the Upgrade:

@11MHz Loss=0.22dBm/meter

@55MHz Loss=0.41dBm/meter

(The cable was 2.07m long. The input signal was +10dBm and the output voltages at the oscilloscope where: Vpk-pk(11MHz)=1.90V, Vpk-pk(11MHz)=1.82V )

Oplev positions before and after drag wiped arm TMs as of yesterday. Slow-mode pumpdown has started with 3/4 turn opened  RV1 valve at 8am today.

They must not be dBm, must be dB

I apologize for the lack of correctness on the units in yesterday's elog entry, but I wasn't very sharp last night.

I repeated the measurement today, this time also making sure that I had a 50ohm input impedance set in the scope. These the results for the losses.

 I also measured the losses in the Heliax cable going from the 166 MHz LO to the LSC rack:

 I'm leaving the lab now for less than 2 hours. I should be back in time for when the pumping is finished so that I can measure the finesse again.

 Seems like very strange cable loss numbers. The Heliax is lossier than the RG-174? I wonder how these compare with the specs in the cable catalog?

Wait, Wait, Wait. You are moving too fast. Go one by one.

Check the PZTs, the MC, initial pointings, IFO mirrors, some of the partial locks, and maybe some momentary full locks?
Once the recover of the IFO is declared, you can proceed to the measurements.

I hope the grad students can take this precious opportunity to have their fun time for restoring everything by themselves.

 Pump down is completed. Valve configuration is VACUUM NORMAL. CC1 pressure is in the ~8 e-5 torr   PSL output shutter is opened.

I did the measurement on a 4.33 meter long cable with SMA connectors at the ends.

In order to enable 'set terminal pdf' in gnuplot on Rosalba/Allegra, I installed PDFlib lite and gnuplot v4.2.6. to them.
(PDFlib lite is required to build the pdf-available version of gnuplot)

Installation of PDFlib lite:

• Building has been done at rosalba
• Download the latest distribution of PDFlib lite from http://www.pdflib.com/products/pdflib-7-family/pdflib-lite/
• Expand the archive. Go into the expanded directory
        tar zxvf PDFlib-Lite-7.0.4p4.tar.gz
      cd ./PDFlib-Lite-7.0.4p4
• configure & make
        ./configure
      make
• install the files to the system / configure the dinamic linker
        sudo make install
      sudo ldconfig

Installation of gnuplot:

• Building has been done at rosalba
• Download the latest distribution of gnuplot form http://www.gnuplot.info/
• Expand the archive. Go into the expanded directory
        tar zxvf gnuplot-4.2.6.tar.gz
      cd ./gnuplot-4.2.6.tar.gz
• configure & make
        ./configure --prefix=/cvs/cds/caltech/apps/linux/gnuplot
      make
      make install
• Create symbolic links of the executable at
        /cvs/cds/caltech/apps/linux/bin
      /cvs/cds/caltech/apps/linux64/bin
• Note: Although the original (non-PDF) gnuplot is still at
        /usr/bin/gnuplot
new one is active because of the path setting
      rosalba:linux>which gnuplot
      /cvs/cds/caltech/apps/linux64/bin/gnuplot


Sometimes back we modified /cvs/cds/caltech/chans/daq/C1ASS.ini to save some of the channels. The file was reverted to default after the recent changes in ASS.

We again uncommented and made acquire=1 to save the following three channels using daqconfig:

C1:ASS-TOP_ERR_MCL_IN1_2048

C1:ASS-TOP_PEM_15_IN1_2048

C1:ASS-TOP_PEM_18_IN1_2048

The script automatically created a back up in /cvs/cds/caltech/chans/daq/archive

We restored the good state of the ITMY camera and neatened both the MC2 and ITMY camera.

The MC2 camera was driving a triple T jungle into some random cables and spoiling the image. We removed all T's and the MC2 camera now drives only The Matrix.

The ITMY camera was completely unmounted and T'd. So it was misaligned just by the force of gravity acting on its BNC cable. We swapped the lens for a reasonable sized one and remounted it in its can. We then used orange cable ties to secure the power and BNC cable for the MC2 and ITMY cameras so that tugging on the cables doesn't misalign the cameras. This is part of the camera's SOP.

No more driving 50 Ohm cables and T's with video cables, Steve! If you need a portable video, just use a spigot of the Matrix and then you can control it with a web browser.

I also wiped out the D40's memory card after uploading all of the semi-useful files to the Picasa page.