From MAILER-DAEMON Sat Feb 21 14:39:35 2004 Date: 21 Feb 2004 14:39:35 -0500 From: Mail System Internal Data Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA X-IMAP: 1077392375 0000000000 Status: RO This text is part of the internal format of your mail folder, and is not a real message. It is created automatically by the mail system software. If deleted, important folder data will be lost, and it will be re-created with the data reset to initial values. From monnier@umich.edu Mon Nov 3 10:32:46 2003 -0500 Return-Path: X-Sieve: cmu-sieve 2.0 Received: from heartbreakridge.mr.itd.umich.edu (heartbreakridge.mr.itd.umich.edu [141.211.125.46]) by mccoy.lsa.umich.edu (8.11.3/8.11.1) with ESMTP id hA3FWkp26306 for ; Mon, 3 Nov 2003 10:32:46 -0500 (EST) Received: (from daemon@localhost) by heartbreakridge.mr.itd.umich.edu (3.8u) with LDAP id hA3FWAa13098 for monnier@lsa.umich.edu; Mon, 3 Nov 2003 10:32:10 -0500 (EST) Received: from fate.mr.itd.umich.edu (fate.mr.itd.umich.edu [141.211.14.75]) by heartbreakridge.mr.itd.umich.edu (3.8u) with ESMTP id hA3FW9b13094 for ; Mon, 3 Nov 2003 10:32:10 -0500 (EST) Received: from sciences.sdsu.edu (sciences.sdsu.edu [130.191.226.112]) by fate.mr.itd.umich.edu (umich) with ESMTP id hA3FW6JU011864 for ; Mon, 3 Nov 2003 10:32:06 -0500 Received: (from leach@localhost) by sciences.sdsu.edu (8.11.6-20030916/8.8.8/SCEC-8.8.8-AS.AR.S5) id hA3FW6N29757 for monnier@umich.edu; Mon, 3 Nov 2003 07:32:06 -0800 (PST) Date: Mon, 3 Nov 2003 07:32:06 -0800 (PST) From: Bob Leach Message-Id: <200311031532.hA3FW6N29757@sciences.sdsu.edu> To: monnier@umich.edu Subject: system Status: R X-Status: A X-Keywords: I think I'm about done with your system, and am sending along a description of the custom features that I included in it for you to review prior to shipment. Bob This is written for John Monnier of the University of Michigan, who asked for a GenIII system (ARC22 and ARC64) to operate traditional two-channel IR video boards. He wants the fiber optic speed to be able to read out quickly. He also asked for subarray readout capability, so portions of Phil Hinz's NICMOS code are adopted. The file "timIRmisc.asm" written for the IRx8 video board = ARC46 will be used, as will the ARC22 file "timboot.asm" from /V1.8/Release_Code, and the utility board support will be left in. Summary: - Gen III operation of two-channel IR video board - HAWAII subarray readout Whole array readout has the same timing as has been used for many years for PICNIC readout. READ is asserted high 5 millisec before readout begins The pixel time is 3.0 microsec LINE alternates high and low for each line's readout Whole array readout will occur if COL_OFFSET = 0 Multiple reads per pixel is not implemented There is a delay of RST_DLY = 50 milliseconds after the end of reset before the first read Subarray readout occurs if col_offset > 0, as follows - The pixel time is 1.0 microsec Multiple reads per pixel is implemented SSA specifies the subarray In both cases number of columns is determined by the value of Y:1 = and the number of rows is determined by Y:2, which are written directly using the write memory command WRM The subroutine to read the array is called RD_ARRAY and is located in the file named "tim.asm". It has these two sets of code interleaved throughout it, one for subarray, fast, multiple read per pixel and the other for slow, whole image readout. This subroutine reads the array once, and is called by the routine START_EXPOSURE located in the "timIRmisc.asm" file. This routine handles the continous readout, samples the trigger if needed, calls array reset and array read. Software commands (1) 'SOS' Ch# To select the output source(s) to be read out. Ch# = 0, 1, 2, 3 or 'ALL' The quadrants are labeled clockwise from the upper left, # 0 to 3 - 0 1 3 2 (2) 'SSA' row_offset col_offset To select subarray mode and set the x- and y- offsets from the edge of the quadrant where readout is to begin (3) 'SNR' number Set the number of reads per pixel, only active in subarray mode (4) 'STM' 0 or 1 A '1' argument will put the controller in trigger mode wherein a TTL pulse on the front panel BNC connector is required to start the exposure. The pulse must be of duration 200 nsec or greater, and the exposure will start about 200 nsec after its rising edge. Default is 0 => trigger not required. (5) 'CDS' 0 or 1 Set readout mode to correlated double sample or not. In correlated double sample mode a frame readout will occur both before and after the timed exposure. (6) 'SRD' 0 or 1 The PICNIC array requires the signal named READ to be turned on during readout. However, it generates a certain glow that gets quite strong for long exposure times. It alse requires a few milliseconds settling time after it is turned on to settle. Therefore, the user is given the option of turning it on and off depending on system requirements. The default is to turn it on and off ('CDS' 1). Then there are two commands to support continuous readout, which is more fully described in the accompanying document 'ContinuousReadout.doc' - (7) 'SNC' # Sepcify the number of frames to coadd in the current sequence. (8) 'FBP' # Specify the number of frames that will fit into the host computer frame buffer that has been allocated. The main area where I feel uncertain is with the resetting of the array. I've put in a delay of 50 milliseconds between the reset and the first read in correlated double sample mode to allow the reset noise to settle down. This is the RST_DLY parameter defined at the end of the "tim.asm" file and used in the START_EXPOSURE routine. The core code for controlling the array readout is as follows - JSR X-Sieve: cmu-sieve 2.0 Received: from heartbreakridge.mr.itd.umich.edu (heartbreakridge.mr.itd.umich.edu [141.211.125.46]) by mccoy.lsa.umich.edu (8.11.3/8.11.1) with ESMTP id hA4ErEp04665 for ; Tue, 4 Nov 2003 09:53:14 -0500 (EST) Received: (from daemon@localhost) by heartbreakridge.mr.itd.umich.edu (3.8u) with LDAP id hA4Eqbg16099 for monnier@lsa.umich.edu; Tue, 4 Nov 2003 09:52:37 -0500 (EST) Received: from oilandwater.mr.itd.umich.edu (oilandwater.mr.itd.umich.edu [141.211.93.145]) by heartbreakridge.mr.itd.umich.edu (3.8u) with ESMTP id hA4Eqb816093 for ; Tue, 4 Nov 2003 09:52:37 -0500 (EST) Received: from mccoy.lsa.umich.edu (mccoy.lsa.umich.edu [141.211.61.24]) by oilandwater.mr.itd.umich.edu (umich) with ESMTP id hA4EqaUX009921 for ; Tue, 4 Nov 2003 09:52:36 -0500 Received: from imager.astro.lsa.umich.edu (imager.astro.lsa.umich.edu [141.211.198.85]) by mccoy.lsa.umich.edu (8.11.3/8.11.1) with ESMTP id hA4ErBp04661; Tue, 4 Nov 2003 09:53:11 -0500 (EST) Date: Tue, 4 Nov 2003 09:52:35 -0500 (EST) From: John Monnier Sender: To: Bob Leach , John Monnier Subject: re: michigan electronics Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: R X-Status: X-Keywords: Dear Bob, Thanks for your message: here are my preliminary responses. > This is written for John Monnier of the University of Michigan, who > asked for a GenIII system (ARC22 and ARC64) to operate traditional > two-channel IR video boards. He wants the fiber optic speed to be > able to read out quickly. He also asked for subarray readout capability, > so portions of Phil Hinz's NICMOS code are adopted. The file "timIRmisc.asm" > written for the IRx8 video board = ARC46 will be used, as will the > ARC22 file "timboot.asm" from /V1.8/Release_Code, and the utility board > support will be left in. OK -- I presume the IRx8 (ARC46) code is compatible with the ARC42 (IRx2)? > Summary: > > - Gen III operation of two-channel IR video board > - HAWAII subarray readout ** These electronics will be used with PICNIC, not HAWAII ** Is this the same for you? > Whole array readout has the same timing as has been used for many > years for PICNIC readout. > > READ is asserted high 5 millisec before readout begins What does this mean exactly? > The pixel time is 3.0 microsec > LINE alternates high and low for each line's readout > Whole array readout will occur if COL_OFFSET = 0 > Multiple reads per pixel is not implemented > There is a delay of RST_DLY = 50 milliseconds after the end > of reset before the first read ** this is _milli_seconds, not Micro seconds? See my questions below about reset transient. So it sounds like this part of the readout is well-tested, vanilla readout, and the next part is the 'experimental' custom part, right? > > Subarray readout occurs if col_offset > 0, as follows - > > The pixel time is 1.0 microsec Does this mean you changed the input RC? to what? > Multiple reads per pixel is implemented > SSA specifies the subarray looks good. Does this routine then allow the subarray itself to be read-out many times before a reset? As you wrote it above, it sounds like the clocking pattern is: a) reset b) go through the pixels of subarray once each (but reading each multiple times) c) reset when done going through one and repeat. Correct? In reality, we will want to then go back and address the beginning of the quadrant and repeat 'nloops' times before resetting (but NOT coadding the frames, rather sending each subarray read to the computer in a continuous fashion). > In both cases number of columns is determined by the value of Y:1 = and > the number of rows is determined by Y:2, which are written directly > using the write memory command WRM > > The subroutine to read the array is called RD_ARRAY and is located in > the file named "tim.asm". It has these two sets of code interleaved > throughout it, one for subarray, fast, multiple read per pixel and the > other for slow, whole image readout. This subroutine reads the array once, > and is called by the routine START_EXPOSURE located in the "timIRmisc.asm" > file. This routine handles the continous readout, samples the trigger > if needed, calls array reset and array read. > Software commands > > (1) 'SOS' Ch# To select the output source(s) to be read out. > Ch# = 0, 1, 2, 3 or 'ALL' > > > The quadrants are labeled clockwise from the upper left, # 0 to 3 - > > 0 1 > > 3 2 > > (2) 'SSA' row_offset col_offset To select subarray mode and set the > x- and y- offsets from the edge of > the quadrant where readout is to begin > > (3) 'SNR' number Set the number of reads per pixel, only active in > subarray mode > > (4) 'STM' 0 or 1 A '1' argument will put the controller in trigger > mode wherein a TTL pulse on the front panel BNC > connector is required to start the exposure. > The pulse must be of duration 200 nsec or greater, > and the exposure will start about 200 nsec after its > rising edge. Default is 0 => trigger not required. > > (5) 'CDS' 0 or 1 Set readout mode to correlated double sample or not. > In correlated double sample mode a frame readout will > occur both before and after the timed exposure. > > (6) 'SRD' 0 or 1 The PICNIC array requires the signal named READ to > be turned on during readout. However, it generates > a certain glow that gets quite strong for long > exposure times. It alse requires a few milliseconds > settling time after it is turned on to settle. > Therefore, the user is given the option of turning it > on and off depending on system requirements. The > default is to turn it on and off ('CDS' 1). Does READ need to be on if we are not using the on-board amplifiers? I thought the IR Labs wiring bypassed this and used the cold JFet source followers (thus avoiding the on-array source follower to eliminate the chip glow?)? Does this have something to do with a long reset-transient? > Then there are two commands to support continuous readout, which is more > fully described in the accompanying document 'ContinuousReadout.doc' - > > (7) 'SNC' # Sepcify the number of frames to coadd in the current > sequence. > > (8) 'FBP' # Specify the number of frames that will fit into the > host computer frame buffer that has been allocated. > > > The main area where I feel uncertain is with the resetting of the array. > I've put in a delay of 50 milliseconds between the reset and the first > read in correlated double sample mode to allow the reset noise to settle Why so long? I thought the intrinsic settline time was like 100- _micro_seconds? Is this from your experience using the IRLabs electronics? I hope not! > down. This is the RST_DLY parameter defined at the end of the "tim.asm" > file and used in the START_EXPOSURE routine. The core code for controlling > the array readout is as follows - > > JSR MOVE Y: JSR > ; Begin the exposure and one or two readouts depending on the CDS setting > JCLR #ST_CDS,X: JSR EX_STRT MOVE #EXP_END,R7 > JMP EXP_END JSR > You should feel free to change this area of the code, especially since its > quite clear that it is impossible to read the array at several hundred > frames per second if there is a 50 millisecond delay every time it is > reset. ok -- we will definitely need it shorter as you say, although I hope the array does not have such a long transient.. See question above. > The exposure control is now set up to expose the array in increments of > one millisecond. This is done with the 'SET' = Set Exposure Time command. > You may wish to have finer control over this timing, which can be done with > a software change. Contact me if you want to implement it. this is probably ok since we will likely not be doing any exposing but reading out as fast as possible (w/o resetting) to minimize readnoise. ---- Thanks for all your work with the custom software part -- it really is essential to our application and will vastly improve the noise performance. So the few loose ends: a) we are using picnic, not hawaii. OK? b) will the subarray readout allow for multiple 'nloops'? That is, we need to be able to vary the number of whole-subarray-reads before reset (while sending out each subarray-"frame" to the computer/interface board in a continous fashion)). c) the reset time is so long, and i would like to understand a little better why. d) Does READ need to be on if we are not using the on-board amplifiers? I suspect yes, but wondering if you know. e) as for continuous readout mode, etc.: my lack of dsp programming and unfamiliarity with the interface board makes it hard for me to digest. However, I presume that any of the above modes can be efficiently readout of the interface board -- it seems clear that even the new mode of reading out a subarray w/o reseting should be accomodated by the Continusou readout since it 'looks' like any other subarray readout (i.e., the fact that there was no resets houldn't change the way the data is handled and moved around internally, right?) thanks for the phone message and email (I seemed to have gotten your emaili on Monday -- not sure why it bounced...) Talk soon about final details, -John ------------------------------------------------- John D. Monnier, Assistant Professor of Astronomy University of Michigan 941 Dennison Building 500 Church Street Ann Arbor, MI 48109-1090 monnier@umich.edu 734-763-5822 (FAX 734-763-6317) From monnier@umich.edu Tue Nov 4 11:58:15 2003 -0500 Return-Path: X-Sieve: cmu-sieve 2.0 Received: from bloodwork.mr.itd.umich.edu (bloodwork.mr.itd.umich.edu [141.211.125.40]) by mccoy.lsa.umich.edu (8.11.3/8.11.1) with ESMTP id hA4GwEp11236 for ; Tue, 4 Nov 2003 11:58:14 -0500 (EST) Received: (from daemon@localhost) by bloodwork.mr.itd.umich.edu (3.8u) with LDAP id hA4GvcG11432 for monnier@lsa.umich.edu; Tue, 4 Nov 2003 11:57:38 -0500 (EST) Received: from granny.mr.itd.umich.edu (granny.mr.itd.umich.edu [141.211.14.70]) by bloodwork.mr.itd.umich.edu (3.8u) with ESMTP id hA4Gvbu11422 for ; Tue, 4 Nov 2003 11:57:37 -0500 (EST) Received: from sciences.sdsu.edu (sciences.sdsu.edu [130.191.226.112]) by granny.mr.itd.umich.edu (umich) with ESMTP id hA4GvaDV030484 for ; Tue, 4 Nov 2003 11:57:36 -0500 Received: (from leach@localhost) by sciences.sdsu.edu (8.11.6-20030916/8.8.8/SCEC-8.8.8-AS.AR.S5) id hA4GvWu02482 for monnier@umich.edu; Tue, 4 Nov 2003 08:57:32 -0800 (PST) Date: Tue, 4 Nov 2003 08:57:32 -0800 (PST) From: Bob Leach Message-Id: <200311041657.hA4GvWu02482@sciences.sdsu.edu> To: monnier@umich.edu Subject: controller Status: R X-Status: A X-Keywords: I'm sending you this email twice, just in case - Bob Dear John, Thanks for your detailed and prompt review. I find if I get too much of a gap on these projects I forget everything. It sounds like I can finish things up in a few days. My note about the 8-channel board (ARC46) was more for my sake so I know what the starting point for the software was. The code you'll get runs on the ARC42 boards that you'll be getting, completely. And, yes, it is the picnic, not hawaii, array that its written for. They're very close, so I often mix them up. Presently, the READ is low during the exposure. After the exposure time elapses the READ signal is brought high, there is a 5 millisecond delay, and then readout begins. This is indeed implemented to reduce amplifier glow which will not be the case for your implementation. I'll leave READ high all the time. I haven't changhed the RC time constant yet. Normally it should be around 1/5 or so of the pixel time, so if you think 1.0 microsec is where you want to be I'll change it to 200 nsec. I'll put code in to sample the subarray multiple times in between resets.. There will be yet another parameter (and command to set it) that specifies the number of frames to read per exposure, and another loop to do it. You just set the exposure time to zero to be in readout mode. a) we are using picnic, not hawaii. OK? Yes, picnic. b) will the subarray readout allow for multiple 'nloops'? That is, we need to be able to vary the number of whole-subarray-reads before reset (while sending out each subarray-"frame" to the computer/interface board in a continous fashion)). Yes, I need to implement this. c) the reset time is so long, and i would like to understand a little better why. I spoke to IR Labs and they said the reset time they now use is closer to 5 milliseconds, not the 50 that we had used a long time ago. Ken at IR Labs thought this could be reduced with some experimentation, and its a free parameter in the software. d) Does READ need to be on if we are not using the on-board amplifiers? I suspect yes, but wondering if you know. I think it needs to be on, but won't do any damage. e) as for continuous readout mode, etc.: my lack of dsp programming and unfamiliarity with the interface board makes it hard for me to digest. However, I presume that any of the above modes can be efficiently readout of the interface board -- it seems clear that even the new mode of reading out a subarray w/o reseting should be accomodated by the Continusou readout since it 'looks' like any other subarray readout (i.e., the fact that there was no resets houldn't change the way the data is handled and moved around internally, right?) Yes, right. So the three things I need to do are - 1. Change the RC time constant to 200 nsec 2. Implement "Number of Frames per Reset" 3. Leave READ high all the time. That's about it. I'll be doing this today. Bob From monnier@umich.edu Tue Nov 4 13:30:29 2003 -0500 Return-Path: X-Sieve: cmu-sieve 2.0 Received: from magnumforce.mr.itd.umich.edu (magnumforce.mr.itd.umich.edu [141.211.14.41]) by mccoy.lsa.umich.edu (8.11.3/8.11.1) with ESMTP id hA4IUTp15481 for ; Tue, 4 Nov 2003 13:30:29 -0500 (EST) Received: (from daemon@localhost) by magnumforce.mr.itd.umich.edu (3.8u) with LDAP id hA4ITq109211 for monnier@lsa.umich.edu; Tue, 4 Nov 2003 13:29:52 -0500 (EST) Received: from neartoearth.mr.itd.umich.edu (neartoearth.mr.itd.umich.edu [141.211.93.141]) by magnumforce.mr.itd.umich.edu (3.8u) with ESMTP id hA4ITps09199 for ; Tue, 4 Nov 2003 13:29:51 -0500 (EST) Received: from mccoy.lsa.umich.edu (mccoy.lsa.umich.edu [141.211.61.24]) by neartoearth.mr.itd.umich.edu (umich) with ESMTP id hA4ITU1Y001692 for ; Tue, 4 Nov 2003 13:29:31 -0500 Received: from imager.astro.lsa.umich.edu (imager.astro.lsa.umich.edu [141.211.198.85]) by mccoy.lsa.umich.edu (8.11.3/8.11.1) with ESMTP id hA4IU5p15462; Tue, 4 Nov 2003 13:30:05 -0500 (EST) Date: Tue, 4 Nov 2003 13:29:29 -0500 (EST) From: John Monnier Sender: To: Bob Leach cc: John Monnier Subject: Re: controller In-Reply-To: <200311041657.hA4GvWu02482@sciences.sdsu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: R X-Status: X-Keywords: Bob -- a few clarifications: > Presently, the READ is low during the exposure. After the exposure > time elapses the READ signal is brought high, there is a 5 millisecond > delay, and then readout begins. This is indeed implemented to reduce > amplifier glow which will not be the case for your implementation. > I'll leave READ high all the time. As it turns out -- we have information Gautum Vasisht at JPL that toggling the READ does have an important effect even when the amps are not used. I excerpt from one of his emails: -------------------------------------------------------------------- By toggling the reads we are able to: 1. limit large excursions (or voltage swings on the output). This improves the effect of any time-constants in the circuit. 2. ensure that biases do not drift as a function of time. Nowadays, In principle a single dark calibration should be good enough for an entire nights operation. In the past this was not true. Drifts of the order of 1 DN matter under low light conndition for fringe tracking. 3. SHould apply to PICNICS as well. It applies to the 1-5 um picnic that I got from ROckwell 3 months ago for FATCAT III. -------------------------------------------------------------------- Unfortunately, Gautum is away at the moment and so we do not know exactly how he toggles it. However, it would be important to have some flexibility to toggle or not to toggle. Currently, with PICNIC camera we are using at IOTA, we do the following (from my colleague Rafael Millan-Gabet): "READ low during reset, high during read frames, goes high after LSYNC and FSYNC ... see Rockwell timing diagram." ==> In conclusion, I think having the option as you originally wrote it would be best (either all high, or toggling). If Gautum Vasisht gives us advice on how to customize it then we will have to figure out how to change it later. > I haven't changhed the RC time constant yet. Normally it should be > around 1/5 or so of the pixel time, so if you think 1.0 microsec is > where you want to be I'll change it to 200 nsec. is 1/5 the pixel time the 'industry' standard to optimize SNR? > I'll put code in to sample the subarray multiple times in between resets.. > There will be yet another parameter (and command to set it) that > specifies the number of frames to read per exposure, and another > loop to do it. That is great. > c) the reset time is so long, and i would like to understand a little > better why. > > I spoke to IR Labs and they said the reset time they now use is closer > to 5 milliseconds, not the 50 that we had used a long time ago. Ken at > IR Labs thought this could be reduced with some experimentation, and its > a free parameter in the software. ok. I guess I should talk with Ken.. > d) Does READ need to be on if we are not using the on-board amplifiers? > I suspect yes, but wondering if you know. > I think it needs to be on, but won't do any damage. yes.. see agove. > So the three things I need to do are - > > 1. Change the RC time constant to 200 nsec > 2. Implement "Number of Frames per Reset" > 3. Leave READ high all the time. see above. > That's about it. I'll be doing this today. good luck! Talk soon, -John ------------------------------------------------- John D. Monnier, Assistant Professor of Astronomy University of Michigan 941 Dennison Building 500 Church Street Ann Arbor, MI 48109-1090 monnier@umich.edu 734-763-5822 (FAX 734-763-6317) From monnier@umich.edu Thu Nov 6 10:17:12 2003 -0500 Return-Path: X-Sieve: cmu-sieve 2.0 Received: from unforgiven.mr.itd.umich.edu (unforgiven.mr.itd.umich.edu [141.211.125.45]) by mccoy.lsa.umich.edu (8.11.3/8.11.1) with ESMTP id hA6FHBp00722 for ; Thu, 6 Nov 2003 10:17:11 -0500 (EST) Received: (from daemon@localhost) by unforgiven.mr.itd.umich.edu (3.8u) with LDAP id hA6FGYd25970 for monnier@lsa.umich.edu; Thu, 6 Nov 2003 10:16:34 -0500 (EST) Received: from idoldancer.mr.itd.umich.edu (idoldancer.mr.itd.umich.edu [141.211.14.76]) by unforgiven.mr.itd.umich.edu (3.8u) with ESMTP id hA6FGXa25959 for ; Thu, 6 Nov 2003 10:16:33 -0500 (EST) Received: from sciences.sdsu.edu (sciences.sdsu.edu [130.191.226.112]) by idoldancer.mr.itd.umich.edu (umich) with ESMTP id hA6FGW0x026554 for ; Thu, 6 Nov 2003 10:16:32 -0500 Received: (from leach@localhost) by sciences.sdsu.edu (8.11.6-20030916/8.8.8/SCEC-8.8.8-AS.AR.S5) id hA6FGT412645 for monnier@umich.edu; Thu, 6 Nov 2003 07:16:29 -0800 (PST) Date: Thu, 6 Nov 2003 07:16:29 -0800 (PST) From: Bob Leach Message-Id: <200311061516.hA6FGT412645@sciences.sdsu.edu> To: monnier@umich.edu Status: R X-Status: A X-Keywords: Dear John, I've implemented the items we discussed in email yesterday, namely the multiple reads per one reset and the time constant of the video board. They're both implemented and tested. I left the control of the READ signal alone. I'm attaching a tar file that has the controller software. It also has a spreadsheet that documents the wiring harness between the controller boards and the front panel where IR Labs will attach their cable. There are also several PostScript files that contain timing diagrams obtained from my logical analyzer that show the timing of the FPA, video processor and image pixel transmit signals. The file name gives some clue as to what mode the controller is operating in. I'm also putting circuit schematics and user's manuals on an ftp site for you, machine name = 'roswell', username = 'incoming', password = 'LetMeIn", directory = 'Monnier'. These are pretty large files that you should copy over in the next two weeks before they get automatically deleted. The system will ship this afternoon and I'll send the airway bill number to you. Bob