% Compute DC fields, and DC signals, and AC transfer functions
% This is a parallelized version of tickle. You have to run matlabpool(n)
% command before using this command. matlabpool(n) will invoke n instances
% of matlab workers in your computer. Once you have started those workers,
% you can reuse them many times (i.e. you don't have to run matlabpoo(n)
% every time you use ptickle). Usually n should be equal to the number of
% CPU cores in your computer, but the Matlab parallel computing toolbox has
% the limit of maximum 4 workers for a local computer. If you use a cluster
% of computers across a network, this limit does not apply. But I haven't
Date-Time * Friday, April 24, 2009 at 03:27:50 UTC
* Thursday, April 23, 2009 at 08:27:50 PM at epicenter
Location 33.910°N, 117.767°W
Depth 0 km (~0 mile) (poorly constrained)
Region GREATER LOS ANGELES AREA, CALIFORNIA
Lock acquisition is proceeding smoothly for the most part, but there is a very consistent failure point near the end of the cm_step script.
Near the end of the procedure, while in RF common mode, the sensing for the MCL path of the common mode servo is transitioned from a REFL 166I signal which comes into the LSC whitening board from the demodulator, to another copy of the signal which has passed through the common mode board, and is coming out of the Length output of the common mode board. We do this because the signal which comes through the CM board sees the switchable low-frequency boost filter, and so both paths of the CM servo (AO and MCL) can get that filter switched on at the same time.
The problem is occurring after this transition, which works reliably. However, when the script tries to remove the final CARM offset, and bring the offset to zero, lock is abruptly lost. DARM, CM, and the crossover all look stable, and no excess noise appears while looking at the DARM, CARM, MCF spectra. But lock is always lost right about the same offset.
I've seen this before. At that time, the problem was gone spontaneously the next day.
You could stop just before the offset reaches zero and then try to slowly reduce the offset manually to see where is the threshold.
Things we noticed: Koji and I had been concerned the last time we were looking at TT#2 because the frequency got lower and the Q seemed to get higher when we added the damping to the vertical blades. Yoichi and I did not find that to be true today. We did notice, however, that the EQ stop screws with the viton had been placed in the holes closer to the clamping point, whereas with TT #4 the screws had been placed in the holes farther from the clamping point. We moved the screws on TT #2 to the outer holes, and noticed that the frequency increased slightly, and the Q significantly decreased. We then followed this outer-hole philosophy when installing screws in TT #3.
The inner and outer screw holes of the EQ stop Jenne is talking about are shown in the photo below.
None of them are working although the computer can recognize that all three DAC cards are mounted.
I think something in the IOP file and the model file may be wrong because this symptom looks similar to that of C1ISCEX we tested two weeks before ( see this entry )
I have to fix it anyhow because the DACs are very necessary part for this damping test.
Since we had a similar trouble with the DAC at CLIO, I checked if this problem comes from the same origin.
The origin of the problem we had was that although the board was sold as 16 channel DAC, the firmware was set to use only 8ch.
To see if this problem exist in the DAC boards of c1sus, I added the following code to the /cvs/cds/caltech/cds/advLigoRTS/src/fe/map.c
printk("DAC ASSC = 0x%x\n",dacPtr[devNum]->ASSC);
in the definition of mapDac() function.
This code prints the information of the ASSC (Assembly Configuration) register of the PMC66-16AO16 board as a kernel message at the start up time of the realtime code. You can check the message with dmesg command.
After the modification, I recompiled the c1sus and installed it.
make c1sus; make install-c1sus
After starting c1sus, I checked the dmesg. Then found that the ASSC register was set to 0x130006. To decipher this magic number, you have to consult with the manual of the DAC, which is available online.
The manual says the 17th and 18th bits of this number set the number of channels. Those bits are 11 for 0x130006. According to the manual, 11 means 16 channels are present. So it seems that the ASSC register is correctly set. In the case of CLIO, the ASSC register was 0x110003, meaning only 8 channels are present.
Unfortunately, the ASSC register was not the cause of the problem, but at least this possibility was checked.