Raw and JPG formats of the pictures are saved on the Mac in the control room and at this link:
The camera was mounted using the JOBE arm wrapped around a small heavy piece of metal. The lights were kept on, the camera was zoomed in as closely as possible (so the light would take up most of the frame), F number of 8 was used, and shutter speeds from 1/2 to 1/100 seconds were used.
The pictures still look a bit blurry, probably because looking back at the details of the image, the focal length was 86.34m (as short of a focal length would be ideal, and Olympus is capable of going down to 1m).
Next steps include looking at the saturation in the pictures and setting up a more stable mount.
Today I measured the dark current of the PDA10CF. The output of the PD was connected to the A channel of the network analyzer, when there was no light falling on it. The response is collected using GPIB.
I will upload the result shortly.
We aligned optics of WFS as it was. Now auto-locker is working to lock MC.
But it still doesn't lock. We notice that the c1lsc machine doesn't work. So we run rebootCILSC.sh.
Now we reset the hardware!
After reset, auto locking didn't work well. Gautum and Aaron reboot slow c1ioo. Then it works, and Gautam returned the MC to a good alignment.
We found the beam is not in the center of the QPD, we (turned off the MC autolocker and MC loop, then) realigned to make beam to get in to the QPD center. Afterwards we start auto locking.
With the WFS on, the maximum MC transmission we observe is 14,700 counts; after the transmission level stabilizes (MC_TRANS pit and yaw brought to 0), the MC transmission is only 14,200 counts. Perhaps the MC_TRANS QPD offsets need adjustment. We relieve the WFS servo of its DC offsets. This is the configuration we'll use for WFS loop measurements this week.
Once stop the auto-locker and realigned to make beam to get into QPD again.
After we lock MC, we took TFs from suspension MC1/2/3 PIT/YAW to WFS1/2 PIT/YAW.
Diagnotics test tools
range: 7 Hz to 50 Hz
Column 0: WFS2_PIT 1: WFS2_YAW 2:WFS1_PIT 3: WFS1_YAW 4: TRANCE_PIT 5:TRANCE_YAW
I'm wondering weather the MC1data I saved is correct, becouse I found the channel was changed when I exported MC2 data. So I took MC1 data again.
We got all data for TFs already. Each data is devided to real part and imaginary part. Then we are arranging the datas to obtain TFs.
TF of MC2 is attachiment 1. So tomorrow, I make other TF.
In the data we got yesterday, we can see some filter's effect.
But it is not good coherence above 10Hz, so we mesured again. And this time we save the data as xml file.
And also we chaned the frequency regions broader to watch corner frequency of suspension.
Diagnotics test tools
range: 0.1 Hz to 100 Hz
but at low frequency, the mode maching cavity was unloked cause of too much shaking.
So, we saw single frequency TF, and searched the good amplitude.
First, I tried to get TF @0.1~1 Hz .
0.1 to 1 Hz
points: 61 (I think it's too much becous it takes about an hour)
The TFs and coherence of MC1/PIT to each QPD is below. [above window: coherence, below: TF]
During the mesurement, something happened @0.2-0.3Hz so I stopped it.
We found the coherence of WFS1P and WFS2Y is not good, but others are good.
we guess that it could come from alignment which made Q chainging to small.
Finaly, I also got the .xml data of MC1P 1 Hz to 10 Hz. In this time,
1 to 10 Hz
Now we took single frequency 6 TFs (MC1/2/3 PIT/YAW) @7Hz (Because this frequency has good coherence in all channel).
Aaron wrote the script using dtt to making matrics.
The compiled version of seisBLRMS had been running ~2 weeks without crashing as of last night, when I killed it
so it wouldn't interfere with alignment scripts. I added an EPICS channel C1:DMF-ENABLE, and updated the DMF
executables to check this channel while running. So far it seems to work. When you're running alignment acripts,
simply click the DISABLE button on the C1DMF_MASTER.adl screen, and then re-ENABLE when the scripts finish.
It's not clear why this is necessary though. Theories include the constant disk access is keeping the
framebuilder busy, reducing its ability to deal with ezcademod commands and DMF programs just flooding the
network with so much traffic that ezcademod-related packets run late and get ignored.
Also, for reasons of aesthetics, I changed the data delay from 6 minutes to 5 minutes. We'll see if that's enough.
> Also, for reasons of aesthetics, I changed the data delay from 6 minutes to 5 minutes. We'll see if that's enough.
5 minutes didn't work.