While I was writing up an elog entry, the elog died again, and I restarted it.  Not sure what caused it to die since no one was uploading to it at the time.

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 Ranger seismometer has been moved to ~the middle of the Mode Cleaner tube, and it's orientation has been changed to horizontal (using all of the locking/mass centering procedures).  This is similar in orientation to the way things were back in the day when Rana and Matt had the OAF running nicely.

  In this experiment, we used a feedback control to create a stable trap for a NdFeB permanent magnet. The block diagram is the following:

signal into another  SR560 as a low-pass filter with a gain of 100 above 30 Hz. We used the "DC" coupling modes in both

preamplifers. The output is then used to drive a coil. The coil has a dimension of 1.5 inch in diameter and 2 inch in length.

The inductance of the coil is around 0.5 H and the resistance is 4.7 Om. Therefore, it has a corner frequency aournd 10/2pi Hz.

The coil has a iron core inside to enhance the DC force to the permanent magnet. The low-frequency 1/f response of the magnet is produced

by the eddy current damping of the aluminum plane that is below the magnet. This 1/f response is essential for a stable configuration. In the

next stage, we will remove the aluminum plane, and instead we will use a filter to create similar transfer function. At high-frequencies, it behaves as 

a free-mass and has a 1/f^2 response. Finally, the magnet is stably levitated.

As noted by Steve, the RFM network was down this morning.  I noticed that c1susvme1 sync counter was pegged at 16384, so I decided to start with reboots in that viscinity.

After power cycling crates containing c1sosvme, c1susvme1, and c1susvme2 (since the reset buttons didn't work) only c1sosvme and c1susvme2 came back normally.  I hooked up a monitor and keyboard to c1susvme1, but saw nothing.  I power cycled the c1susvme crate again, and this time I watched it boot properly.  I'm not sure why it failed the first time.

The RFM network is now operating normally.  I have re-enabled the watchdogs again after having turned them off for the reboots.  Steve and I also re-enabled the ITMY coil drivers when I noticed them not damping once the watch dogs were re-enabled.  The manual switches had been set to disabled, so we re-enabled them.

The PSL enclosure HEPAs turned on at 30%

The RFMnetwork is down.  MC2 sus damping restored.

I disconnected the setup for the arm cavity TF measurement. I opened the scitation switch on the ISS medm screen. I reconnected the OMC ISS EXC cable to the breakout box on the floor.

The photodiode on the Y end is stilll connected.

Also the RFAm (whish is not disbaled anymore) still has a 50% beam splitter before it.

I'm also running the Align Full IFO script.

 Measurement repeated with the PDA255 PD at the end but not big changes

The elog just crashed and I rebooted it

As for the X Arm, this the transfer function I measured for the Y arm cavity.

This time I'm using a different photodiode than the PDA255 on the Y end table.

The diode I'm using is the PDA520 from where TRY comes from.

I'm going to repeat the measurement with PDA255.

It seems that just repeating the measurement was enough to get a good transfer function of the x arm cavity. Here's what I got.

I'm going to fit the data on matlab, but at first sight, the pole seems to be at about 1.7KHz (that is where the phase is 45deg): as expected.

Probably it was useful to realign the beam on the Transmission PD. (btw, I'm using the PDA255 that was still on the X end table since the AbsL experiemtn that measured the arm length)

On Rana's suggestion I measured the trasfer function between the two photodiodes PDA255 that I'm using.

I took the one that I had on the end table and put it on the PSL table. I split the MC transmitted beam with a 50% beam splitter and sent the beams on the two diodes. (Rana's idea of picking off the beam and interposing the PDs before the ISS PDs was not doable: ISS PDs would be too close and there would be no room to install the PDA255 before them). See picture with the final setup.

The transfer function also includes the 40m long cable that I was using for the Arm Cavity measurement.

Here's what I got. It looks rather flat. Yesterday the calibration was probably not the problem in that measurement.

 I'm now going to install the PD back on the end table and measure the TFs between the excitation and several points of the loop.

(Trivia. At first, the PDs were saturating so Koji attached attenuation filters on to them. Suddenly the measurement got much nicer)

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.

 Joe and I moved megatron and its associated IO chassis from 1Y3 to 1Y9, in preparations for RCG tests at ETMY.

Joe, Peter, Jay, Koji, Rana

We put the new CDS stuff at Y end 1Y9 rack.

Items

• megatron
• wireless router
• IO chasis (black)
• Extention cable (between megatron & IO chasis)
• 1 ADC card
• 1 DAC card
• 1 BIO card
• The adapter box for ADC
• The adapter box for DAC
• The adapter box for BIO
• 2x IDC-DB37 cable for the ADC box - AA chasis
• 1x IDC cable for the DAC box - Pentek
• 1x DB cable for the BIO box
• 1x +/-15V cable for the BIO box

The on/off switch for the drill press is broken.  Replacement parts should be here tomorrow. 

I found elog got crashed. I rebooted the elog daemon just 10minutes before.

I would have guessed that you have to calibrate the detectors relative to each other before trying this. Its also going to be tricky if you use 2 different kinds of ADC for this (c.f. today's delay discussion in the group meeting).

I think Osamu used to look at fast transmission signals by making sure the PD at the end had a 50 Ohm output impedance and just drive the 40m long cable and terminate the receiving end with 50 Ohms. Then both PDs go into the SR785.

I measured the transfer function between MC_TRANS and TRX and I'm attaching the result.

That looks quite strange. Something's wrong. I'll repeat it tomorrow.

for the night I'm putting everything back. I'm also reconnecting the OMC_ISS_EXC and opening again the test switch on the ISS screen.

The RFAM monitor remains disable

 Back from dinner. Taking measurements.

 Since I need to measure the transfer function between TRX and MC_TRANS_DC I picked off the beam going to RFAM PD to send it to a PDA255 photodiode (cannibalized from the AbsL's PLL) which I installed on the PSL table.

I centerd the beam on the PD and I was able to see the injected signal.

I think I'm ready to measure the transfer function.

Except for the RFAM PD everything is as before.

I'm gonna go grab dinner and I should be back to keep working on that in about one hour.

I'm going to work on the X arm to measure the arm cavity finesse.

The idea is to measure the cavity transfer function to estimate the frequency of its cavity pole. That should be a more accurate measurement than that based on the cavity decay time.

I'm starting now and I'm going to inject a swept sine excitation on the OMC_ISS_EXC input cable laying on the floor nearby the AP table (see pic).

In orderf to do that I disconnected the cable from the OMC breakout box laying on the floor. I'm going to plug the cable back in as soon as I'm done.

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.

This level of frequency noise has not changed, but we now have increased common mode servo gain and so it's not as huge of a deal, although we should still probably do something about it. 

Attached is a plot of the piezojena noise measurement, estimated into Hz, along with another measurement of frequency noise as described above. 

To get the piezojena voltage noise into Hz, I estimated the PZTs within have a flat 2 micron/V response (based on a rough knowledge of their geometry and assuming a 10 milliradian / 150V steering range).  This is the voltage noise with the PZTs operating in closed loop mode, which is how we normally run them.  This plot also ignores the transfer function of the Pomona box, as we are mainly looking at noise in the kHz band.  I think this plot shows that these PZTs are a good candidate for creating this frequency noise, especially near their mechanical resonances (the manual says the unloaded resonances are in the 3-4kHz range).   

I've been operating one DOF of the piezojenas in open loop mode for a couple of weeks now, and the feared drift has not been a problem at all.  If we plan to keep using these after the upgrade, we should definitely put some big resistors in series at the outputs and operate them in open loop mode.

Also attached is a plot of RF DARM noise, with a frequency noise spectrum.  That spectrum is a REFL 2I spectrum put into DARM units using a measured TF (driving MC_L and measuring REFL 2I and DARM_ERR), and then put into meters using the same DARM calibration as used for the DARM curve.

I made some changes in the code (all commented in the installed and SVN version) to print the filter coefficients. I got crazy output. Sometimes memory bugs lead to such crazy behavior. So far I could not find any bugs, but will have to spend more time on it.

The cables labeled "Gur2" which were connected to channels 2,3,4 of the PEM-ADCU have been moved to the PCIX ADC which is connected directly to the ASS machine.  This means that until I (a) put the cables back or (b) figure out how to route channels from the ASS ADC to the RFM, we won't be able to use these channels for environmental monitoring, nor will they be saved. 

The Gur2_X, Gur2_Y, Gur2_Z channels are now connected to the 2nd, 3rd and 4th ADC channels respectively, on the ASS ADC (the first channel / TP1 is ADC0_0, which is the 1pps signal.).  The sketchy thing about the setup is the connection between the cables and the new ADC board.  The PCIX card is connected to the ASS via a white ribbon cable, and the board is just sitting on top of the computer box.  The 1pps (which has been hooked up for a long time) goes into the board via clip-doodles.  The regular channels have a SCSI cable connector, so I used a SCSI cable to connect up the ADC tester board, and connected my seismometer inputs to this tester board via more clip doodles.  Clearly this is a sketchy solution, and not okay for more than a day or so.  But we'll see how it goes. 

I'm going to, on the SimuLink Diagram, change the input source of these channels, from the RFMN to the ADC.  Then we'll see if that fixes our timing problem, and magically makes everything relating to the OAF work, and subtract huge amounts of noise. 

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.

The beam to PMC aligned. The beam to MC WFS cameras aligned.
PMC Trans increased from 2.73 to 2.75 (+1%).
MC Trans increased from 7.80 to 7.87 (+1%).

As I wrote on Oct.27th, the cron job works every Sunday.

I found it worked well on the last Sunday (Nov.1st).

And I can not find any timing jitter in the data, its delay still stay 3*Ts.

The current update on the Chameleon video switch is: no progress.

I connected the old laptop that Rob/Steve acquired via RS-232 serial to the back of the video switch.  I'm using P2, the same serial port that the C1AUX computer was connected to just in case there's something good about P2 vs. P1. 

I used HyperTerminal to (try to) talk to the switch.  Settings were:  COM1, bits per second = 9600, data bits = 8, parity = none, stop bits = 1, flow control = none.  I can successfully send/get back responses to the basic commands, I (inquiry as to the type of equipment), and H (help - spits out the list of acceptable commands).  But when I try to do an actual command to do some video switching, everything hangs.  The front panel's rolling display (which just echos the company name) stops, then starts up again after ~20sec.  The hyperterminal display doesn't change.  I get neither the "DONE" answerback, which would indicate that the command executed successfully, nor do I get the "ERROR" answerback, which would indicate that something is wrong.  It just hangs.  If I disconnect, and restart the connection, and instead of trying a real command, but instead just send 'blahblahblah', then it will answerback 'ERROR' the first time, and then if I try to send another garbage message, everything hangs again.  So, I can sort of talk to the video switch, but I can't make it do anything yet.

I'm leaving the laptop connected instead of C1AUX, since the video EPICS screen doesn't work anyway for now.  If you want to start up the connection, either input the settings quoted above, or open "40m Video", which should have these connection settings saved in HyperTerminal.

Zach found the HEPA switch on the PSL table OFF.  He turned them on.

 Koji did a nice job increasing light power with some joggling.

I never actually figured out exactly what was wrong in entry 2162, but I managed to circumvent by changing the time sequence of events in the up script, moving the big gain increases in the common mode servo to the end of the script.  So the IFO can be locked again.

The problem has returned.  I still don't know what it is, but it's making me angry. 

Here is the plots for the powers. MC TRANS is still rising.

What I noticed was that C1:PSL-FSS_PCDRIVE nolonger hit the yellow alert.
The mean reduced from 0.4 to 0.3. This is good, at least for now.

We are manually restarting assepics, but the terminal logs us out after sometime and ass may crash. I set autologout=0 in the terminal for the time being. Once the testing process is over, assepics will start automatically when the computer is turned on, so we wont have to worry about this.

(if ass crashes tonight, it is not unexpected!)

[Sanjit,Jenne]

Sanjit has been working today on trying to get the OAF coefficients to save properly.  Alex got us most of the way, but right now it's looking like the filter that is being saved is totally constant (all the values are the same).  We're poking around trying to figure out why this is. 

Also, we're starting again (as we should have been for the last week or so since Alex came in to help us) to check in the TOP_XFCODE whenever we make changes to it, and when we recompile the front end code. 

13:00 Found MC TRANS less than 7.
13:50 Go into the PSL table.
14:20 Work done. Now I am running SLOWscan script.
15:10 SLOWscan finished. It was not satisfactory. I go into the table again.
15:15 Running SLOWscan again.
16:00 SLOWscan done. Lock PMC. Adjust NPRO current so as to maximize PMC TRANS.
16:10 Lock RC, PMC, MZ, MC. Align PMC / MZ on the table. Align MC WFS beams on the QPDs.
16:30 Work done.

New FSS-SLOWDC nominal is -4.0

Now MC TRANS is 7.9. This is +12% increase. ENJOY!
HEPA is on at 90%. Light is off.

---------

NPRO TEMP trimmer adjustment
o PSL NPRO TEMP trimmer at the back of the laser head was turned 6.5 times in CW.
o It reduced NPRO crystal temp by 9.5deg. (43.5deg -> 34.0deg for FSS_SLOWDC -5.5)

To revert the previous setting, refer to the former measurement
c.f. http://nodus.ligo.caltech.edu:8080/40m/2008

NPRO Thermal scan
o 2 scans are performed.
o I selected the colder side of the second scan. i.e. SLOWDC=-4.0

NPRO Current adjustment
o Tweaked C1:PSL-126MOPA_126CURADJ while looking at PMC TRANS.
o CURADJ was changed from -2.25 to -1.9. This corresponds to change of C1:PSL-126MOPA_CURMON from 2.503A to 2.547A.

This is a plot of the R and T of the existing ETM's HR coating. I have only used 1/4 wave layers (in addition to the standard 1/2 wave SiO2 cap on the top) to get the required T.

The spec is a T = 15 ppm +/- 5 ppm. The calculation gives 8 ppm which is close enough. The calculated reflectivity for 532 nm is 3%. If the ITM reflectivity is similar, the signal for the 532 nm locking of the arm would look like a Michelson using the existing optics.

Illuminators and PSL lights turned off.
HEPA filter speed increased from 20 to 100%

The PMC power is seems to be on the rise, ( MOPA_AMPMON is dropping ?) but I do not think it is real. We have Santa Anna wind condition, when the relative humidity drops and  ......

There is an other funky think. The room temp became rock solid. The PSL HEPAs running at 20% and IFO-room ACs are also in normal operational mode.

LockAcq is back on track, with the full script working well.  Measurements in progress.

I set a cron job on allegra.martian to run the diagnostic script every weekend.

I think this routine can be helpful to know how the trend of timing-shift goes

The cron runs the script on every Sunday 5:01AM and diagnostics will take about 5 min.

! Important:

During the running of the script, OMC and DARM can not be locked.

If you want to lock OMC and DARM in the early morning of weekend, just log in allegra and then comment out the command by using 'crontab -e'

 This problem has disappeared.  I don't know what it was. 

The first plot shows one of the symptoms.  The second plot is a similar section taken from a more normal acquisition sequence the night before.

All is not perfect, however, as now the handoff to RF CARM is not working.

A 30-day trend of the PCDRIVE from the FSS.

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 was working on the ISS excitation to take TFs.

I used ISS IL excitation, stealing from a small box on the floor for the OMC.

All the configuration was restored except that the HEPA is on.

I adjusted the steerings to the PMC and gained 7%. Now the MC_TRANS 7.0 has been recovered.

Actually I need another 7% to get MC_TRANS 7.5.
But I couldn't find how I can recover 126MOPA-AMPMON to 2.8ish.