| Date | Who | Subject |
| This line intentionally left blank. | ||
| 2003 February 11 | Tom Bida | bleed valve |
| IRCAM is installed and runs fine. The bleed valve has also been moved downstream of the solenoid so we shouldn't have to use the same LN2 supply tank. Nothing will be done at the 42" today. | ||
| 2003 January 27 | Tom Bida | IRCAM focal plane mask installed |
| I understood that you wouldn't be using IRCAM tonight, right? The telescope is currently parked at the zenith. I'm coming out early AM to install a special mask at the focal plane. IRCAM is unmounted, so the telescope is quite unbalanced. Call me of course if indeed you are planning on running it! | ||
| 2002 August 20 | Tom Bida | IRCAM cold again |
| No real alarm last night; a midnight fill (while the camera was still cooling down) simply sent T > 86 (the alarm point). A steep cooling curve and ultimate low T (78 K) this time have resulted from a modification to the cold strapping. Let's hope for a long, uninterrupted cold spell for IRCAM! | ||
| 2002 August 1 | Tom Bida | IRCAM warm, vacuum problem |
| To make it generally known, IRCAM is warm and will be brought into the lab the week after next to fix a vacuum problem. The autofill solenoid is disconnected and should remain so to prevent fills. | ||
| 2002 June 29 | Tom Bida | IRCAM unintentionally warmed |
| The IRCAM warmed up early this morning likely due to low pressure in the supply dewar, preventing complete fills during the 20min timeout period. I've manually filled the dewar now and have extended the timeout. Amanda, please be aware that IRCAM may dump LN2 early this evening even for moderate zenith distances. | ||
| 2002 June 13 | Amanda Bosh | IRCAM minimum exposure time |
| After Brian changed the timing offset to 1 second, I re-ran our linearity test to check for the time constant, and found.... 0.03 seconds! This was a rough analysis (i.e. no lamp drift accounted for), so I consider this close enough to 0 for government work. Many thanks to Tom and Brian for coming out tonight to measure this and change the code. | ||
| 2002 June 13 | Brian Taylor | IRCAM filters switched, cooled down |
| IRcam is on and happy in both lois and old lois. Filter values have also be changed for both configurations. | ||
| 2002 May 30 | Brian Taylor | IRCAM warmed up, filters changed |
| IRcam is warming up and I have turned off the warning messages. | ||
| 2002 May 15 | Ralph Nye | IRCAM weight settings |
| IRCAM Weight setting is: A B = 45 C D =58 Slide Weight =23" | ||
| 2002 May 14 | Tom Bida | IRCAM filter cable replaced |
| Another cable has been swapped in for IRCAM filter control, and the wheel has been moved at least 6 round trip cycles from J to K and beyond and back to home without fault. | ||
| 2002 May 14 | Brian Taylor | IRCAM filter cable suspect |
| We think that the RS232 cable to the filter control is the cause of the filter move problems. Tom replaced it yesterday and there has been no software changes to the filter controller. He is going to put the old cable back and we will test it. | ||
| 2002 May 13 | Svetlana Jorstad | IRCAM filter wheel not functioning reliably |
| I started to observe with the IRCAM on 13/14 May. There is a terrible situation when you change filters between J and K positions and back: every 15 min you have an error: Command Interp. Error. Error sending filter command to instrument thread 0! and Wheel Status is unknown so that you need to restore Home Filter and then change to filter K and you can have the same error many times in raw. At 10 p.m. Lois suddenly crashed: Tcl_Release couldn't find reference for 0x6b3f8 LOIS Caught Abort Fault Signal gcore: core.14693 dumped sh: /opt/LOIS.1.3.0.6/scripts/movecore: not found Svetlana Jorstad | ||
| 2002 April 17 | Brian Taylor | Change IRCAM minimum exposure time |
| During Alan Marscher and Svetlana Jorstad run with IRcam the concern that the timing for the intergrations time were not as good as we thought that they were due to the rebuild in the IC Linux Box. The process for takeing a CDS exposure is 1) Reset each Quad in sequence (Q1,Q2,Q3,Q4) 2) Non-Destructive Read in sequence. 3) Integrate 4) Non-Destructive Read in sequence. Before the rebuild, when we first worked through the timing of the read out of the entire array. We found that the total time was 528ms. So to get the delay between Non-Destructive Reads we use Exposure Time - 528 = Integration Time. With a 0 integration time being equilivent to a 528ms expsosure time. Using a Oscilloscope watching pulses of the Command trigger Ted and I found the following. 1) That the integration time error is so small that it is beyond the ability of the oscilloscope to measure with out more electronics. My current estimate of the error is less than 100us. 2) The time difference between the Reset and the first read is not consistant. Errors are on the order of +/- 6ms 3) Errors between Quad Reset Pulses are on the order of +/- 200us 4) Errors between Quad Read Pulses are also too small to measure with current setup. Error estimate is at the less than 100us level. 5) We were only able to eyeball how the time interval on 120sec exposure and that looks as thought it is pretty good. My recommendation for changes to the driver level code would be to put the CDS Reset into the driver. Currently it is being called from the application layer where the read-integrate-read is being handled in the driver layer. This put the most important part of the CDS exposure in the driver/kernel layer where the real time maintain better control over the timing. Also I think that the min exposure time should be changed to 614ms the time from the first pulse of the first read to the first pulse of the second read. Below is a table of the results from this afternoon.... Comments, Questions, Disagreements???? Cheers, Brian At 0sec with the First Quad Pulse as Reference All in ms: Process Run_1 - Diff_1 Run_2 - Diff_2 Run_3 - Diff_3 Reset Q1 0 0 0 Reset Q2 151 151.0 151.5 151.5 151.5 151.5 Reset Q3 302.5 151.5 302.5 151.0 302.5 151.0 Reset Q4 454.0 151.5 454.0 151.0 454.0 151.5 Read Q1 633.5 179.5 636.0 182.0 631.5 177.5 Read Q2 787.0 153.5 789.5 153.5 785.0 153.5 Read Q3 940.5 153.5 943.0 153.5 938.5 153.5 Read Q4 1094.0 153.5 1096.5 153.5 1092.0 153.5 Integ. Read Q1 1247.5 153.5 1250.5 154.0 1245.5 153.5 Read Q2 1401.0 153.5 1404.0 153.5 1399.0 153.5 Read Q3 1554.5 153.5 1557.5 153.5 1552.5 153.5 Read Q4 1708.0 153.5 1710.5 153.0 1706.0 153.5 At 0.542 sec requested exptime ==> 542ms- 528ms = 14ms integ. Process Run_1 - Diff_1 Run_2 - Diff_2 Run_3 - Diff_3 Reset Q1 0 0 0 Reset Q2 151 151.0 151.0 151.0 151.0 151.0 Reset Q3 302.5 151.5 302.5 151.5 302.5 151.5 Reset Q4 454.0 151.0 454.0 151.5 453.5 151.5 Read Q1 631.5 177.5 632.0 178.0 632.5 179.0 Read Q2 785.0 153.5 785.5 153.5 786.0 153.5 Read Q3 938.5 153.5 939.0 153.5 939.5 153.5 Read Q4 1092.0 153.5 1092.5 153.5 1093.0 153.5 Integ. Read Q1 1259.5 167.5 1260.0 167.5 1260.5 167.5 Read Q2 1413.0 153.5 1413.5 153.5 1414.0 153.5 Read Q3 1566.5 153.5 1567.0 153.5 1567.5 153.5 Read Q4 1720.0 153.5 1720.5 153.0 1721.0 153.5 Diff between Second Read Q1 and Integ. ==> 14ms+153.5ms = 167.5ms At 1 second requested exptime ==> 1000ms - 528ms = 472ms Diff between First Read Q4 and Second Read Q1 = 625.5 ms ==> 625.5 - 153.5 = 472 also repeatable exactly over three integrations. At higher Oscilloscope Sweep... The first Reset pulses look like this: Process Run_1 - Diff_1 Run_2 - Diff_2 Run_3 - Diff_3 Reset Q1 0 0 0 Reset Q2 151.4 151.4 151.2 151.4 151.4 151.4 Reset Q3 302.6 151.2 302.6 151.4 302.6 151.2 Reset Q4 454.0 151.4 453.8 151.2 454.0 151.4 | ||
| 2002 April 15 | Brian Taylor | IRCAM exposure times incorrect |
| While looking into the problems over the weekend I found a MAJOR problem on the rebuilt linux CCD controller. The problem is in how the exposure time was being handled and every exposure time over 65535 milliseconds is wrong. Looking back through the logs for incorrect times: Requested(ms) Actual(ms) 120000 54464 180000 48928 240000 43392 300000 37856 600000 10176 I have gone back through the logs to make sure and the dates that observers took images greater than 65535ms appears: 03/22/2002 -- Observer not on the web Schedule -- Amanda? 04/08-15/2002 -- Jorstad/Marscher This problem is now fixed. | ||
| 2002 March 28 | Brian Taylor | IRCAM IC rebuilt |
| The IRcam IC has been rebuilt and is functioning properly. I am concerned that we have may have lost the PC11 card in the old IC system as I was unable to get it to respond in the new system. We are starting to run out of spares for this configuration. | ||
| 2002 March 25 | Brian Taylor | IRCAM IC dead |
| I was unable to get the IRcam IC to come up today. Apparently yesterday's blackouts finished the job on it. I will take out our last spare system and get things up and running again before Amanda's run on the 30th. | ||
| 2002 January 17 | Tom Bida | IRCAM available |
| The IRCAM is fully operational and available for use on the 72" tonight (and beyond). Two problems were fixed: a 4-bit receiver in the serial data sender in the Rapax electronics had failed and was replaced, and unstable power to a shift register in the serial data receiver in the computer room was resolved. The detector operates over its full data range now. | ||
| 2002 January 16 | Tom Bida | IRCAM not available |
| IRCAM's control electronics have been removed until a replacement part is found that should cure the bit problem. The telescope has been stowed. | ||
| 2001 December 20 | Tom Bida | IRCAM stuck bits |
| I worked on one of your IRCAM flat field images, adding 4096 to those pixels with substantive negative counts, and this corrects for the bit problem. Presumably all of your data can be corrected this way, though we do need to explore the dynamic range of the effect. The example corrected file can be found at: /pinyon/data0/ircam/ircam.328.fixed.fits Note that the detector is characterized by a number of unresponsive or poorly responsive pixels, which is apparant in the corrected file above. Historical bad pixel maps are available, however, recent maps may also be available from regular users. Let me know if you need more information on this. | ||
| 2001 December 20 | Brian Taylor | IRCAM stuck bits |
| Using Phil's imhist suggestion I took several random image from last night and found the following is pretty consistant between images: 1) The bad pixels are isolated from -4085 to -4005 2) The peak value of bad pixels is around -4074 3) The sky produces a pretty broad histogram from about 10 to 40 in value. 4) The peak value of sky pixels is around 22 Since these are CDS images implies that a pixel would get stuck at 4096 and subtracted from 22. But the really odd thing is that there is no congregation of pixels at a positive 4096. This seems to lead to the reset of the frame as a possible cause to the problem as the order of a CDS image is reset the array read the array integrate read the array and subtract the first read from the second. So at first blush, I think that the reset of the array is where we need to look. | ||
| 2001 December 20 | Ted Dunham | IRCAM stuck bits |
| Ken, Tom, Brian - As I was driving home last night it occurred to me that the bad pixel problem we were seeing might be related to the intermittent stuck bit problem that has been reported before in various of the data bit values, but in this case in a high order bit. We've never been able to track this down properly because it only happens sometimes. It would be worth a check to see if adding increments of 1024, 2048, or 4096 would make the data look correct. - Ted | ||
| 2001 December 20 | Ken Janes | IRCAM stuck bits |
| Well, we worked most of the night (through increasingly thick cirrus) trying to learn how to use IRcam. There is certainly some sort of problem with the data. There are regions of the image where the data values are down by increments of almost 1000. It seems to be very regular, in the sense that an individual pixel is down by one "unit", two units, etc. I haven't had the time to figure out what that unit is. For a good example of what I am trying to say, take a look at /perkins/data/pcdata/011220/011220.328.fits Get into IRAF imexamine and do a row plot through a row near the center of the image. When we tried to do an exposure longer than about 2 seconds, the system would hang for more than a minute, before finally completing the cycle. We have connected the dewar to IRcam, and it seems to have filled itself. Since the weather prognosis is not good, perhaps the best would be to put the Loral back on. We might be able to "exercise" it a little and get some pretty pictures, even if there are some clouds. | ||
| 2001 November 28 | Tom Bida | IRCAM window iced |
| I came out to dust off the IRCAM window, and found it iced up. I propose to leave main power on, to hopefully raise the temperature in the guider area enough to keep it dry. A longer term solution is necessary, but if anyone objects to this please call me at the 72" now. | ||