The channels for IPPOS had been assigned in a wrong way.
Because of this, C1:ASC-IP_POS_X_Calc corresponds to the actual vertical motion and C1:ASC-IP_POS_Y_Calc is for the horizontal motion.
We should fix the database file to get the correct vertical/horizontal corrdinate.
Today Steve was working around the 1X5 rack to strain relief the cable jungles and the jungle is now getting less jungle.
During the work he disconnected and reconnected some cables.
So for a doublecheck I checked all the suspensions to see if the suspensions are still healthy or not.
Aha, then I found a mistake.
See the pictures below. It's a very subtle difference. This wrong connection prevented MC1 and MC3 from damping.
To balance the actuation on ETMX and ETMY, x4.12 was aded to C1:SUS-ETMX_(UL|UR|LR|LL|SD)COIL FM1. OSEM damping filter gains, oplev loop gains, and alignment offsets were divided by this factor.
C1:LSC-ETMX_GAIN is now 1.
- Balance ETM and ITM. It should make ASS more sensible.
- Re-commission Xarm ASS and Yarm ASS.
C1:LSC-ETMX_GAIN is now 1.
We aligned and locked xarm for green.
That's really, really awesome!
Yend seismometer isolation kit (elog 8461) hosts Guralp seismometer. I made a cable for inside connection, assembled the kit and relocated the instrument from its previous position at the yend inside the kit.
Seismometer is connected to the readout box and running.
Xend internal cabling and external connector is ready. We are waiting for seismometer from Gyro lab. We still need to fix the pot with clamps after we put the instrument in.
We also need a long cable from Xend to the guralp readout box.
We aligned and locked Y arm for green:
I've switched error channel cable to output monitor. Whitening filter is need for scattering measurements.
As a CM slow path test I locked free swinging yarm by actuating on MC length with bandwidth of 200 Hz. Crossover with AO is not stable so far.
I used xarm as an ool frequency noise sensor. MC2 violin mode is at 645 Hz, I have added a notch filter to LSC-MC2 bank.
I went to Ottavia, and tried running yum update. It was having dependancy issues with mjpegtools, which was a rpmforge provided package. In order to get it to update, I moved the rpmforge priority above (a lower number) that of epel ( epel -> 20 from 10, rpmforge -> 10 to 20). This resolved the problem and the updates proceeded (all 434 of them). yum update on Ottavia now reports nothing needs to be done.
I went to Rosalba and found rpmfusion repositories enabled. The only one of the 3 repositories in each file enabled was the first one.
I then added priority listing to all the repositories on Rosalba. I set CentOS-Base and related to priority=1. I set CentOS-Media.repo priority to 1 (although it is disabled - just to head off future problems). I set all epel related to priorities to 20. I set all rpmforge related priorities to 10. I set all rpmfusion related priorities to 30, and left the first repo in rpmfusion-free-updates and rpmfusion-nonfree-updates were enabled. All other rpmfusion testing repositories were disabled by me.
I then had to by hand downgrade expat to expat-1.95.8-8.3.el5_4.2.x86_64 (the rpmforge version). I also removed and reinstalled x264.x86_64. Lastly I removed and reinstalled lyx. yum update was then run and completed successfully.
I installed yum-priorities on Allegra and made all CentOS-Base repositories priority 1. I similarly made the still disabled CentOS-Media priority 1. I made all epel related repos priority 20. I made all lscsoft repos priority=50 (not sure why its on Allegra and none of the other ones). I made all rpmforge priorities 10. I then ran "yum update" which updated 416 packages.
So basically all the Centos control room machines are now using the following order for repositories:
CentOS-Base > rpmforge > epel > (rpmfusion - rosalba only) > lscsoft (allegra only)
I'm not sure if rpmfusion and lscsoft are necessary, but I've left them for now. This should mean "yum update" will have far fewer problems in the future.
I added the following repos which I found on allegra to megatron and then did a 'yum install sshfs' on both machines:
-rw-r--r-- 1 root root 428 Feb 12 16:47 rpmforge.repo
-rw-r--r-- 1 root root 684 Feb 12 16:47 mirrors-rpmforge
-rw-r--r-- 1 root root 1054 Feb 12 16:47 epel-testing.repo
-rw-r--r-- 1 root root 954 Feb 12 16:47 epel.repo
-rw-r--r-- 1 root root 626 Feb 12 16:47 CentOS-Media.repo
-rw-r--r-- 1 root root 1869 Feb 12 16:47 CentOS-Base.repo
-rw-r--r-- 1 root root 179 Feb 12 16:47 adobe-linux-i386.repo
This also required me to import the rpmforge GPG key:
sudo rpm --import http://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt
For several of the channels on the PEM ADCU, zeros are occuring at the same time. Does anyone know why that might happen or how to fix it?
Added zita to the martian host table, and configured his network accordingly:
zita A 192.168.113.217
I installed 'nfs-client' on zita (the StripTool terminal). It now has mounted all the shared disks, but still can't do StripTool since its a 32-bit machine and our StripTool is 64.
I'll finish the rest of the config to turn it into a full-fledged workstation tomorrow.
Here is a comparison of the response of various DoFs in our various RFPD sensors for two different CARM offsets. Even in the case of the smaller CARM offset of ~1kHz, we are several linewidths away from the resonance. Need to do some finesse modeling to make any meaningful statement about this - why is the CARM response in REFL11 apparently smaller for the smaller CARM offset?
If you mistrust my signal processing, the GPS times for which I ran the sensing lines are:
CARM offset = ~30kHz (arm transmission <0.02) --- 1257064777+5min
CARM offset = ~1kHz (arm transmission ~5) --- 1257065566+5min
There seems to be stronger-than-expected coupling between CARM and the 3f sensors.