Xiao's 2011July run

2011July4th & 5th

testing saving data. note: the dewar was pumping down, and hadn't been cooled down yet.

I ran RTSchedule and spooler under "xche@mirkwood:/MIRC/" with sudo, the camera setup was rows=16, cols=252, row off=5, col off=2, Nreads=5, Numberoffremes=1000, framesperreset=1000, which is the prism mode. I saved 65 files, and there were 8 files with frame countererror (missing one frame). The ratio was unusually high. (file No.: 0-64)

I changed the setup to rows=48, cols=252, row off=5, col off=2, Nreads=5, Numberoffremes=500, framesperreset=500, which is the grism mode. I saved 70 files, and only one file has frame countererror!! (file No.: 64-134)

changed back to prism mode. I saved 40 files and 6 of them has the frame countererror.

changed back to grism mode. saved 60 files and one of them has the frame countererror.

rebooted mirkwood, and using prism mode, still a lot of frame counter error. It tends to happen continuously, sometimes only received 0 frame out of 1000.

changed to grism mode, no error at all on spooler saving 45 files, but there is error on RTschedule just after saving data finished:

Timeout on blocking semaphore !!! numberCoherent: 10, numberOfCoadds: 15, savenum: 0 ERROR: Starting exposure failed -> 0x544F5554

I doubled the poolsize, but I can't even run the RTschedule.

I reduce the poolsize by half, the IRCam crashed. Also there were still frame counter errors. (I just notice that the UT time went into July 5th, is this the reason causing the crash?). I tested again, saved 70 files, no crashes, but >10 frame counter errors.

I restore the poolsize back. After restarting VME (VME was on), the situation seems better. I saved 100 files in prism mode, and only 5 of them have frame counter error, and all of them received 99X out of 1000 frames. And in grism mode, I saved 70 files, and one of them have the frame counter error.

Although these two modes both have frame counter error, but they are essentially different. In grism mode, when the error happens, it prints out the message length which is a very large number. But in prism mode, there is no such printouts.

July 6th

The the best focus positions of MIRC fibers have drifted about 50 microns in xy direction. The photometric channels have also drifted, mostly on the beamsplitter side. I have to rotate the beamsplitter to get most of light back, but the PC flux is still lower than before, about half. I need to do a better alignment if I have time in the future. I also found fringes on beam56, beam45, beam34. We somehow solved the dispersion problem of fringes in beam56, we really don't know why. And also the flux between different beams are all over the place. I need to do a better focus and measurement tomorrow.

The retro positions are different from before. beam56: retro = 10.43mm beam45: retro = 5.08mm beam34: retro = 2.25mm

Here are the images. Media:beam56_2011July.png

Media:beam56a_2011July.png

Media:beam56b_2011July.png

Media:beam45_2011July.png

Media:beam45a_2011July.png

Media:beam45b_2011July.png

Media:beam34_2011July.png

Media:beam34a_2011July.png

Media:beam34b_2011July.png

July 7th

I focused the fibers better and measure the flux in each neighboring pairs. The fluxes of beam 1, 2, 6 are about the same, beam 3 is about 90%, beam 4 is about 50%, beam 5 is about 80%.

Notice: we realized that beam1,2,3 had pavo splitters in, which reduced about 30% of light. When measuring beam 12 and beam23, the splitters are in. When measuring the rest, splitters are out.

Media:beam12_flux_comp_2011July.png

Media:beam23_flux_comp_2011July.png

Media:beam34_flux_comp_2011July.png

Media:beam45_flux_comp_2011July.png

Media:beam56_flux_comp_2011July.png

July 8th

We squeezed fibers of beam 4,5,6 today. Here are how the fringes look like after squeezing, including beam12 and beam23 which look like before.

Media:beam12_fringes_2011July.png

Media:beam12a_fringes_2011July.png

Media:beam23_fringes_2011July.png

Media:beam23a_fringes_2011July.png

Media:beam34_fringes_2011July.png