From James.Synge@acm.org Wed Nov 14 11:56:15 2001 Date: Tue, 6 Jun 2000 22:40:09 -0700 From: James Synge Reply-To: videoastro@egroups.com To: videoastro@egroups.com Subject: Re: [VIDEOASTRO] Introduction, Snappy and Field of View Charles Allison wrote: >Check out my web site at http://freeweb.pdq.net/pja/cba.htm for a simple >snappy sequential capture program (hard coded to 10 seconds) and also for >modifications to the pc23c for manual shutter and gain control - very useful >for moon and planets. Note that the time delay is caused by data transfer >and not by display but running it too fast (in the version 1.0 version of >the sdk) can freeze or abort capture. My web searches had already led me to your interesting site. The capture program I've written seems to be able to work at a little under 3 seconds per snap. I'm using moving image mode, so just one field of the frame is captured. The program has no display of data, saving raw (unprocessed) data to a file as it goes. My thought is to then process the data later. I realized earlier this week that I can actually get trickier about this. I can hook the snappy up to my wife's laptop on our deck, so that I'm next to the scope. I can then hook up an ethernet 100-T connection to my pc inside. The machine in the house could do the processing, after the laptop saves the files across the net. Boy, what overkill! :-) I feel like I'm making a Rube Goldberg mousetrap. :-) >To view more of the sky - you'll need an attachment lens that is a focal >length reducer. Is there a reducer that works for a newtonian? >Also, if you use Visual C++ 5.0 or later, you're welcome to my source code >for the Snappy sequential capture program. Thanks, I'd love to have a look at it. >The problems with using the vid camera like the pc23c is really that of >timing integration. 1/60th second is just not enough for deep sky photon >collection and there will be a readout noise associated with the output of >the ccd into the video. Cooling might help a tiny bit - but it shouldn't be >necessary for such short exposure times. I've been assuming that 'dark current' is reduced by cooling, but not readout noise. Is that so? I talked with Richard Berry about the cookbook camera, and he said that the readout noise was virtually eliminated just by slowing down the readout. James ------------------------------------------------------------------------ Remember four years of good friends, bad clothes, explosive chemistry experiments. http://click.egroups.com/1/4051/0/_/8698/_/960356573/ ------------------------------------------------------------------------ From James.Synge@acm.org Wed Nov 14 11:56:15 2001 Date: Wed, 7 Jun 2000 23:18:16 -0700 From: James Synge Reply-To: videoastro@egroups.com To: videoastro@egroups.com Subject: Re: [VIDEOASTRO] Introduction, Snappy and Field of View Charles Allison wrote: >The display time for the raw image is insignificant to the capture/transfer >time of the snappy so there is really no need to deny yourself instant >viewing. I wanted to know whether this was true sometime back, so I wrote a snappy test program to find out. It turns out that about half the time is spent doing what the Snappy docs call Acquiring and Analyzing. The other half of the time is spent on what they call Processing (not the same as working with Photoshop or some such). So, my experiments indicated that I could double my frame rate by not doing the 'processing' synchronously. > My sequential capture routine simply uses the stored settings made >by the main snappy ver 1.0 capture program or at least those settings which >the ver 1.0 sdk makes use of. For simplicity I hard coded the time and >selected 10 seconds to insure that there was plenty of time to capture one >frame prior to time out in any settings. A worthy addition would simply be >to allow a capture on demand - say using the space bar. Another good mod >would be to allow the setting of the time - say from 3 or 4 seconds to 30 >or 60 seconds. Note that for some reason, the snappy driver doesn't like >mouse and keyboard activity during capture - I had to disable those inputs >to prevent a problem. Good ideas. I think the reason for the mouse/keyboard problem is that the interrupt rate is so high while it is aquiring the image via the parallel port. This makes me wonder whether my idea of network file transfer will run afoul of this issue. >>>Also, if you use Visual C++ 5.0 or later, you're welcome to my source code >>>for the Snappy sequential capture program. > >>Thanks, I'd love to have a look at it. > > >I'll try to zip up the stuff and email you a copy in the next coupla days. I look forward to it. At the moment my program is hard coded, and command line oriented. It definitely needs improvement, so maybe some 'cross-pollination' from yours will help me to improve. James ------------------------------------------------------------------------ Win a trip to Vegas for you and 20 friends, $15,000 and a suite at Bellagio for New Year's, courtesy of Expedia.com. Or win 2 roundtrip tickets anywhere in the U.S. given away daily. Click for a chance to win. http://click.egroups.com/1/5293/0/_/8698/_/960445422/ ------------------------------------------------------------------------