The following are Mark IV design notes by Tom Droege, as posted in the TASS maillist, and as exerpted by Herb Johnson. No guarantees as to completeness or relevance to the current state of the Mark IV design, but these notes will likely be informative, at least until something more current is available. My comments or deletions are in []'s. Herb Johnson Feb 15 1998 ------------------------------------------------------ Date: Thu, 05 Jun 1997 12:09:00 -0600 From: Tom Droege Subject: News from the Amateur Sky Survey To: ccd@wwa.com, tass@wwa.com News from The Amateur Sky Survey 970605 Progress continues on the Mark IV camera. We have seen "first light" by a very loose definition. Nothing close to an image, but we have all the proper clocks working and can see the expected signals from the CCD amplifier. We have backed off on the read out speed for the first units after looking at the signals coming from the CCD. We will now read out the 2k x 2k device in 40-50 seconds for the first camera. But faster 16 bit ADCs are coming, and we have designed the system to read out as fast as 2 MHz. All the mechanics for the triplets have been designed and are ready to go to the shop. The package is 16" x 16" x 24" and will contain 3 ea. 2k x 2k cameras all looking at the same patch of sky with V, R, and I filters. We uncovered a major problem with the memory board. It forgets after a few milliseconds. Just what one would expect. We are doing a major redesign. Possibly we will be able to kludge it up to work in a few weeks so we can try to get an image with the hay-wired but working electronics. [snip] .....The Control board was made to work, revised, and we already have a new board back from the PC house which we have started to assemble. The Scanner board is being revised to run with a 16 bit 10 us ADC. There was just too many things that could go wrong with the fast two step converter. The memory board is being worked on. Next Month (June): This month will be clean up month. We should get the revised Scanner board out in time to have it back in June. Meanwhile we will try to get the memory working so we can try to see an image. We hope to start the memory board PC revisions. We plan to completely revise the design so we can run a triplet of cameras with one PC and one memory board. We will also go to AAS and tell everyone what we have been doing. Tom Droege -------------------- The Mark IV is a stare mode 2k x 2k camera designed for general purpose use. It features high speed read out (2-4 seconds) and two step conversion for wide dynamic range. We plan to build a bunch of them, so we are trying to do a finished engineering design. Not a commercial design that we could sell without support, but still a design that we can ship out around the world and get operational with internet correspondence. I will try to get one of these out monthly to keep everyone abrest of the project. Mostly I do these for my own benefit to force me to think about the details of the schedule and whether there is some critical path item that I am missing. First a little outline of how the project is organized. Such projects have a design phase where one just thinks about it and collects information. Then there is an implementation phase where one executes the design. The Mark IV is in the implementation phase. The implementation phase has a paper design phase, a printed circuit board layout phase, and a test phase. We are now in the test phase. Later there will be a programming phase, but I don't like to think about that. Last month I wrote: We expect to complete all the PC board layouts this month (March 1997). With normal 3 week deliveries, we will start getting boards back from the vendor in early April. By the end of May we should have all the boards working, and will be starting to write test camera code in BASIC. We did that, and all the boards are back! This for my physicist friends that are not used to doing anything on a schedule. There are four main boards: The Control Board: This board is centered around the BASIC Stamp computer. It communicates with a computer over an RS-232 interface. It contains a 16 bit 10us ADC and a 16 channel multiplexer that is used to monitor operating voltages, temperatures, and the like. It contains circuits to generate 16 pulse outputs to control things, besides the 16 general purpose I/O lines on the stamp. I contains an 8 way input sense multiplexer to sense single bit conditions. It contains a stepper motor driver for the Declination motion, and a clock and a half step stepper motor drive for the RA drive. There is also a power amplifier and servo for controlling the TEC cooling. There is an octal DAC with buffer amplifiers that is used to generate the CCD clock voltage levels. The Scan Engine Board: This board controls two prom controlled scan engines. One is used for the vertical pulse generation. It has eight outputs and is started by a pulse from the Control Board. The condition of the output lines is determined by an 8 bit by 128K prom. It can be clocked up to about a 14 MHz rate. This allows a different state of the clock lines every 70 ns. A second scan engine, used for the horizontal clocks has 16 outputs, and is again 128k long. The way it works, the vertical engine puts out a vertical clock sequence at the end of which it starts the horizontal engine and pauses. The horizontal engine then puts out a sequence for a full horizontal line, then continues the vertical engine. With the 128K proms, we can handle comfortably CCDs to 8k x 8k or larger. The scan engine board also contains the dual slope double correlated sample electronics, and gain switching amplifiers so that we can perform two conversions per pixel to get wide dynamic range. My guess is that this will never be used, but it will be there if we need it. The scan engine board contains DC-DC converter modules which get +12 volts DC from the PC and generate +/-5, +/-15, and +20 for the various circuits. The Memory Board: The memory board is built on a standard PC card. It accepts 8 bit wide data (from the Scan Engine board) and stuffs it into a one byte by 16 meg memory on the card. It is a simple card. You send it an byte of data and a clock and it puts it into the next memory position. You can only reset the memory address counter to zero. To load the memory, the Scan Engine checks that it is empty, then jams it full and sets a done flag. At the PC, the done flag can cause an interrupt, which can then be used to reset the memory address counter followed by single byte reads. The PC must know how many bytes to read. The Camera Head Board: The board in the camera head receives DC voltages from the Control card DACs and clock pulses from the Scan Engine. In camera head switches connect to the DAC voltages to generate the clock line signals. Note that the DG-403 switches used are the present speed limit for the clocks. There is also a JFET buffer amplifier for the pixel signal. Both outputs of the Ford chip are buffered but there is only one signal line brought to the ADC on the Scan Engine card. The Mechanical Hardware: The plan is to build a barn door type mount. The Other Stuff: The plan is to build a complete system. So there is other stuff to think about. Status of Construction: The Control Board: We have established communication with the Stamp. We send 6 ascii character strings to the stamp. The center two characters are used as check characters. While we send full bytes, only the low order 4 bits are used. This (I think) allows use with almost any RS-232 device, since you can usually pick out a sequence that does not contain anything nasty. We are using (at the moment) 0-? which is 30-3F in hex. We have checked out the pulse generation circuits and can generate the 16 pulses to do various things. We have tested the 16 bit ADC and the multiplexer. We can send commands from the PC like "read the +15 supply" and get back the current value. A little noisier than I would like, about 1 mv rms, but everything is still out in the open. We have the DACs working. We can send a DAC address and a value and read the output voltage which swings about +/- 12 volts. We have the declination drive working. We can send a direction and a number of steps from the PC and the motor does the right thing. Left to test are the status sense circuits, the declination step motor drive and clock, and the power servo for the TEC. There are lots of blue "correction" wires. We will have to have this board re-done at least once. We have used the pulse output to start and stop the vertical scan engine. The Scan Engine Board: Both scan engines have been wired. The vertical scan engine has been given a few tests. Everything works as expected. Again there are a bunch of correction wires because we mixed up inputs and outputs on a simple AND gate. Sigh, it took forever to find as the drawing had the pins wrong. Since both scan engines were done from the same PC layout symbol, the second scan engine should test quickly. The power supply modules have been installed and the mis-wirings repaired. Yet to be tested is the analog circuitry and the flash ADC. The Memory Board: Is stuffed, but not tested? The Camera Head Board: Is here and fits in the camera head hardware but is otherwise untested. The Mechanical Hardware: We have had pieces machined for a camera head and a simple barn door mount. We have redesigned almost everything. (one piece can be reused). We have decided to use a 2" square filter. The prototype was machined with the idea we would use a 3" round window and sit the filter on top of it. Now we plan to use a 2" square filter as the window. The barn door mount was a little stuffed in it's 1' cube enclosure. We have now decided to build a triplet in a 16"x16"x24" enclosure. This gives a longer arm on the barn door and allows finer steps (about 5") with the step motor and lead screw that I have. We have completed drawings for all the mechanical parts. The Other Stuff: We have worried a lot about grounding and shielding and how we might operated in the field. It should only be necessary to turn on the PC and start the program. The system then has handles to turn on everything else, like pumps, TEC power supplies, door openers, and the like. There are also sense inputs to make sure that what was supposed to have happened actually happened. We have packaged everything so that it will be very difficult to wire it up incorrectly. This means we have used almost evey DB connector in the series. A pain in the neck from a stocking standpoint. My work room is full of piles of connectors. Drawings: We have pretty finished drawings for everything. At last count over 50 B size drawings. We continue to update the drawings as we make changes and are checking out the hardware using the final drawings. Some of you will appreciate what this means for the final quality of the documentation. Anecdote of the Month: Just to show what all this is about, here is what happened when checking the serial DACs. The DACs require a 12 bit serial input and a clock. The Stamp has a SEROUT instruction. You specify a word to be sent, whether the most significant or least significant bit should be sent first, and how many bits to send. Given that a sixteen bit word was used, that 12 bits were to be sent, and that the most significant bit was to be sent first, guess which bits the stamp sends? No fair answering if you have used one. Tom Droege June 1997 From: droege@wwa.com Subject: TASS - News From The Front To: tass@wwa.com [extract] I have had the Mark IV camera head apart so many times that wires have started falling off it. Thursday night a clock line fell off and I had the opportunity to try to figure out why the camera was not working when most things seemed normal. Just had to go through and check everything. Yesterday I carefully took things apart and cleaned up all the connections, dressed the wiring, and set out to put the camera permanently together. I wan un-hurried, and working carefully so as to get the camera in shape to take sky pictures. I was so careful and un-hurried that I plugged in Chip 17-0-0 90 degrees from it's proper position. Sigh! 180 degrees would have done no damage, but 17-0-0 is now in that great silicon valley in the sky. I am now testing with 14-0-0. The 0-0 0-1 ect. reffers to the quadrant of the wafer that the chip came from. One thing I learned was the chips were pretty much alike. I am still not using the chips that are supposed to be the best. I have tried to compare MPP with NMPP modes. I see very little difference in the saturation level. That is when I expose the chip (through a lens) so that some areas are saturated. Possibly 65,000 e- in NMPP mode and 55,000 e- in MPP mode. This led me to wonder if I was really running in MPP mode. So I have just done a dark current test. I clear the chip several times and note the dark level. Then I wait 3 minutes and look again noting the dark level. Temperature Mode Dark Current -25 C NMPP 80 e-/sec -34 C NMPP 21 e-/sec -25 C MPP <10 e-/sec The above were taken with three minute pauses between clears. I am doing a longer run while typing this to try to get a better measure in MPP mode. Tom Droege [end extract] Date: Mon, 18 Aug 1997 14:56:32 -0500 (CDT) Subject: TASS - Eye Have a First Mark IV Picture To: tass@wwa.com, richmond@astro.princeton.edu Hello everyone, The official "first" mark IV picture is now up on storm/incoming. It is a 400 pixel in x by 750 line in y picture of an American Optical Eye chart. This picture is un binned, and is the upper left hand corner of the frame. It is about 7% of the whole picture. It includes all the edges so you can see what problems there are. There is lots of dirt on the CCD. It came with no cover and over the couple of years that it has been sitting in a drawer and been looked at in the open by everyone (including me) it has accumulated a lot of dust. I have not (yet) tried to clean it. The streaks are probably not dirt, but I am betting on them being in the CCD. There is one obvious vertical bad pixel in this part of the frame. (There are several others.) The format is binary 16 bit integers. Just 300,000 of them. But the file seems to have lost a few, and I am not going to try to transmit it again from home. You experts at reading stuff like this should know that Basic reverses the bytes from the order of most stuff. Each line is 800 bytes long, just 400 signed integers. There are then 750 (less a few lost in transit?) lines. The picture was taken with a 57mm focal length, f/1.4 Konica lens. The distance to the eye chart was about 11 feet. Lens was stopped down as far as it would go, which I estimate as f/32. Last marked position is f/16. Exposure was as fast as I could remove the lens cap and replace it. About 1/2 second. Michael, I hope you can decode this and put it up on the home page. Tom Droege Date: Thu, 21 Aug 1997 12:09:14 -0600 From: Tom Droege Subject: Re: shutter Arne and all, My speed assumption on the Mark IV is that no exposure would be less than 100 seconds. To get more sensitivity than the Mark III, we need to run at of order 1000 seconds. I am not trying to build an instrument that does everything. I priced large fast shutters at prices similar to the CCD. Too much for me. Hmmmm! How does a shutter really affect the exposure when it is an opening slit? I recall focal plane shutters work by driving a slit across the film plane. Yep, I thought about the "curtain shutter", but it just took too much space. In general, I expect timed operations to be done by the PC. One would only do "limit of speed" operations in the stamp. While I am trying to include in the design the ability to run one camera at a time, I am really planning on exposing and reading them out together. Sigh! OK, the next version of the mount will reach the Pole. I will shoot for 135 degrees in declination. But I expect to use the part near the horizon as a built in flat field screen. It seems to me that there is plenty of science to be had between the Pole and the Equator. My idea is to build a bunch of cameras and put one in the south, or at the equator to see the galactic bulge. I have long fought "escallating greed" in the design of experiments. It is this sort of thing that gets us a Sloan that can't be built. So I will fight to keep the design simple and limited. But I do listen, and will add all that I can for a good reason. Tom Droege Date: Tue, 02 Sep 1997 13:03:35 -0600 From: Tom Droege Subject: TASS [shutter] To: tass@wwa.com I spent a good part of the weekend working on the shutter for the Mark IV. The little model airplane servo really works great. Easy to control from digital logic. The scheme is to have a long plate with a hole in it. Move hole from left to right over the CCD to open. Continue moving right to close and end the exposure. Next exposure make similar moves left. This has the advantage that all areas of the window are equally exposed. I found a nice linkage to couple the rotary motion of the servo to the linear motion of the shutter. Works very freely (if I keep away from aluminum to aluminum sliding contact). The problem is the inertia of the shutter. That little servo really gets the shutter moving and it wants to stay moving. I am presently using a brass (0.012") shutter because aluminum likes to stick when it runs on aluminum. Sigh! I will end up doing materials research before I am done. My next try will probably be a brass foam sandwich. Hmmmm! I think I will try a brass (say 0.001" brass) balsa wood sandwich. The alternative is to just slow it down with software. Little steps work fine. Arne, I know how your camera works, but it takes two motors (or solenoids) to drive it. Still trying to do it with one. This scheme takes a lot of space. I my yet go back to the parlor door scheme since it is compact, and give up on the uniformity for short exposures. Tom Droege Date: Fri, 19 Sep 1997 16:57:22 -0500 (CDT) From: droege@wwa.com Subject: TASS Hardware Progress To: tass@wwa.com [snip] This morning I turnd on the shutter to open and close every 4 seconds and just let it run for a couple of hours. So it looks like it will last the life of the machine. I have gone back to the parlor door scheme. Not as uniform an exposure as the sliding window scheme, but takes much less space, and does not have as large an inertia problem. I really like the model aircraft servos. They are impressive in their degree of engineering perfection for the price. They also generate a lot of force. 20 ounce inches for this one. No moth is going to lay eggs on the rails and stop the motion. Looks like it opens in about 0.2 second. Should not produce much of an error for the expected typical 500 second exposure. OK, not so good for sky flats. Can't have everything. Today I also wired up the first limit switch and got it working. There are just lots of connections to sort out and identify. Get addresses right so I am looking at the switch I think I am etc.. The RA and Declination motors are hooked up and the Declination motor has been tested. It will cover about 70 degrees. From near vertical. The next hardware will have much more motion in declination - I should be able to get near 180/degrees which is more than what is needed. The RA drive works, I have just not connected it up to the proper motor drive yet. This is the one with the precision VCO. I have changed the design for the next version so I will be able to fast slew it where I want it. This version only tracks forward at sideral rate, then fast slews back. This makes it a pain to test as it takes a long time to make moves. I made a bad choice in mounting the drive so instead of 20 degrees of good motion I have possibly 10. That is enough for a longer exposure than I expect to make. Again, the next version will fix this. Now that I have metal bolted together I can see how I should have designed it and where things should be mounted. Still, this mount will be plenty good for tests. It can travel more than I can see between my trees. The hope is to get the Mark IV up on the roof in a week or so. Tom Droege Date: Fri, 21 Nov 1997 14:00:38 -0600 (CST) From: droege@wwa.com Subject: Mark IV To: tass@wwa.com I keep working away on the Mark IV. I have looked a lot at what I see with the prototype and have made some decisions. 1) I am not going for fast read out at this time. I am not burning bridges and could go faster in the future by replacing one PC board. This design will take 40 seconds to read out. This will hold true whether there are 1 or 4 camera heads attached to the control box. I figure that the first use of the Mark IV will be for an all sky survey similar to the present Mark III survey, but covering the whole sky from several locations. For this, we might do a 500 second exposure. This means a 90% or better duty cycle. This is good enough for me. I would rather have the 16 bit ADC that I understand than some of the new devices that are much faster. The new devices are bound to want to teach me something, and that is a slow and painful process. Besides, it is not so easy to have the ADC and the data source separated. I want to do this for practical operation reasons. Time helps a lot. 2) I have looked into ways to get blue response. Not very encouraging. The problem with the blue band is that the CCD has about 1/2 the response of the other bands on the red side, and near zero on the blue side. This must be awful for calibration to the standards? What say Arne? In any case, I would plan to build quads, in the faint hope that we find a solution. Lockheed does not offer lumigen coating which would help in spite of what the data book says. One can get the chips thinned, but apparently by sending them to someone in Texas. One can guess what that might cost. My understanding is that you buy the chips and send them with the hope that some survive the process. We could run a blue camera and just live with the fact that after we fix up the filter that it is many mag less sensitive from the rest of the channels. What say? 3) I have been struggling with the packaging. There are three main worries. Lightning, noise, and cost. As one might expect what is good for one is not good for the others. One of my goals has been to design the system so it could be cabled up with low cost cables that you could buy at the computer store. DB cables, BNC cables and the like. But it looks like it just can't be done and still be secure from lightning and also be low noise. So I will make special camera cables. Sigh! I hate making cables. Ah! But this is a job that someone might volunteer to do. No amateur cable makers need apply. Making good cables is one of the toughest jobs in the data business. 4) I am designing the Mark IV so that it is not possible to bin the data. I know this is desirable for focusing. The 40 second read out time will be a pain for focusing. At least my experience on the Mark III is that focusing is not at the top of the problem list. Sure we could gain from a better focus. At least my practical experience is that it is more important to get data every day one can than to get better data by spending more time fussing. There is a trade off. Right now I think the best plan is to get pretty good data with many measurements. The firmware actually allows two programs, and one could be set up to read out a small area - say the center - pretty fast. So this could be a focusing solution. 5) I have backed off somewhat from when I am trying to get the Mark IVs out the door. I have been sick for over a months, and an just starting to feel better. So the old schedule is shot. I think I will watch what is coming out of the Mark III data and try to adjust the Mark IV design for an optimum result. Tom Droege Date: Wed, 07 Jan 1998 13:04:06 -0600 To: gp@io.astrouw.edu.pl (Grzegorz Pojmanski), tass@wwa.com From: Tom Droege Subject: Mark IV Electronics Design This is mostly a reply to Grzegorz Pojmanski who is interested in using the Mark IV electronics. I am posting it to the group as there may be general interest. The status today is that there are rough drawings for everything. The connector details have not been worked out. All the labels of signals between boards have to be determined. We started board layout today. This is the second generation design. The first is working on the bench if I can remember all the things required to turn it on. Note that the big change has been going from a design that required a computer for each channel to single computer, four channel design. The Mark IV electronics will consist of 5 "logical" printed circuit boards. I may package these as one or two physical printed circuit boards. If one, it would be about 10" x 20". It is usually cheaper to make a single board if my vendor does not barf at the size. In any case, it will be laid out as 5 boards and pasted together as needed. The boards are: Stamp Scanner ADC Motor TEC Memory These boards will all now live in the telescope housing. This greatly reduces the number of cables that have to go from the telescope to the control room. The disadvantage is that the electronics now must operate at telescope temperatures. I figure -20 C to +30 C. Someone might let me know what the 20 year low temperature is at the observatory of your choice. Stamp The stamp board is the control center. It receives commands over an RS-232 cable from the control room and controls everything else. It contains: 1) A 32 channel 16 bit data system to measure all the important voltages and temperatures. 2) 16 each 8 bit DACs. These are used for CCD clock levels, offset adjustments, RA drive speed trim, and temperature commands for the TEC. 3) 24 Output pulses. These can be used to set registers, start and stop things, and drive model airplane servos who's position is proportional to pulse width. 4) An 8 bit bi-directional data bus. This is set up to have 16 logic level sense channels as well as being the way to load 8 bit registers for various purposes. Scanner This board receives start and stop pulses from the Stamp board and generats the necessary clocks (under PROM control) to scan a CCD chip. There are 8 pulse channels for the Vertical scan and 16 for the horizontal scan. It is set up for one program of 128,000 steps or two programs of 64,000 steps. A 64k step program would allow 32 micro steps for each pixel read during the horizontal scan. Sounds like a lot, but one quickly uses them up. On can get down to 100 ns or so micro step width, though 200ns is the more practical limit. The plan is (at the moment) to use one program to read out the whole chip and a second for focus. Read out time for the whole chip is 40 seconds. We might read out the center area of the chip in 1 or 2 seconds for focus. Note that there is no provision for binning. We have not provided the clocks that are needed. This would be a whole new design. ADC This board contains 4 ADC channels. The first version will use a 10 us ADC chip, the ADS7805. This chip is cheap, works well, and has a 16 bit resolution if not 16 bit accuracy. The four channels drive produce 8 bytes of data per pixel scanned from the four CCDs simultaneously. Note that there is no provision to scan one chip while exposing another. All the CCDs must be exposed and read out at the same time. If alternate exposure and read out is desired it will require a second set of electronics, and probably a second computer to receive the data. The electronics is not a big expense on the scale of things. Much lest than the cost of a CCD chip. The ADC board drives a DB-25 cable that connects to the Memory board. Motor The motor board contains a bunch of misc. stuff that does not conveniently go anywhere else. The stepper motor drives are bi-polar drives with current control. This means they have a built in current sense and turn off the current so is free wheels when it gets to some limit. This makes for a very efficient stepper motor drive with faster response than the common 2R system. The chip is rated at 45 volts and 1000 ma, but I would not get very close to this limit. Some of the things it contains: 1) A VCO and RA drive stepper motor. The VCO is set by a pot and trimmed by a DAC under program control. A temperature sensor on the board will allow trimming the VCO to hold it constant under temperature. There is no good way to get a fast measure of the VCO frequency. I will bring a cable back to the control room so it can be monitored and trimmed using a frequency meter. One can also do it slowly using the PC clock. The problem here is that The only way to get time information back to the PC is through the RS-232 line. This means something not so good time wise in both the Stamp and the PC. So I can't promise how well this will work. One can always just take a long time to make the measurement. 2) Five additional stepper motor drives. Run under program control from the Stamp. 3) Eight Model Airplane Servo drives. Four are used for the shutters. The rest are available for things that can be done with a shaft that makes roughly a 180 degree rotation. The rotation is proportional to pulse width, about 1 degree steps can be made. Motors are available with response times of 150ms for 60 degrees, and torques up to 200 Oz In. 4) 16 logic level sense inputs. We will provide 4 pin connectors that convently drive the common IR LED/Light Sensitive Transistor devices. One just needs to stick some sort of vane between the poles of the device, and it will sens it. On can reliably detect a limit position to 0.001" 5) An 8 bit control register. I plan to use four of these lines to provide 4 switched AC outlets on the side of the telescope housing. One to turn on the TEC high current power supply, one to turn on the cooling water pump. This leaves a couple to power AC motors to do things like open the dome. There is no problem switching a killowatt these days with available SCR switch modules. 6) I will probably double up the connector to this board from the stamp. This will allow building the interface of your choice with the 8 bit bus and available control pulses. TEC The TEC board contains 4 power amplifiers and comparator circuits to drive the TECs in the camera head. It receives DAC temperature commands and feedback signals from the thermisters in the camera head and drives the TEC appropriately. Memory The memory board is 32 Mbyte board which can be expanded to 64 Mbytes. 32 is probably enough memory for three channel systems where we will start. This board lives in the PC. It is read out over the I/O bus. It can interrupt the PC, but otherwise it is a pretty simple board. It can have its memory address set to zero, and can accept bytes over the cable. It automatically advances each time it gets a byte. If it gets out of sync with the data, that is just tough. Cables With this design, there are only two cables between the control room PC and the camera. One also needs AC power and a cooling water pond at the camera site. I expect the system to work fine with 100' cables. There is no real limit. I think you can go 1000' feet or so with a properly designed RS-232 signal. One might have to slow down the read out for very long cables. But this is possible to do. I have worried about sensitivity to lightning. We will see if I have worried about the right things. ---------- Grzegorz is planning to run a telescope of his own design. So he has asked questions about how he might operate. I will probably package the Stamp, the Scanner, and the ADC on one printed circuit board, and the Motor and TEC on another. Running a camera head separately would then only require the Stamp combination board since the controls would be elsewhere. The TEC could just be driven manually. In actually fact, the boards will be quite cheap once in production on the scale of things. Grzegorz will probably want the full compliment, just because it might be useful to have one of the features on the motor board. One can always leave most of the parts out for the small saving in parts but larger savings in stuffing labor and testing. Tom Droege Date: Thu, 08 Jan 1998 21:20:36 -0600 To: tass@wwa.com, Chris Albertson From: Tom Droege Subject: Re: Mark IV Electronics Design [Chris suggested using a PC parallel port like interface.] Chris, As outlined some time ago, this has long been done. The problem was to design an interface that was data push. The receiving end has no control. I did not want the read out from the chip to vary in speed as would be the case with any computer interface. i.e. from time to time the computer wants the interface and holds things up. So the design is a straight byte parallel interface designed to go at up to a 20 MB or so rate (for a short cable). So it is not any standard interface. Tom Droege To: tass@wwa.com, "Griffing, Dan" From: Tom Droege Subject: RE: Mark IV Electronics Design [Dan et al suggested Ethernet or other fast data/control interfaces.] Dan, The basic problem is that I don't have a live in programmer, or any way to muck with system functions. When I run my computer it from time to time goes off and does something. This is the essence of multitasking systems. I want to unload the cameras in one continuous operation. This is because I have experience with systems where the computer takes a few cycles here and there. The result is a noise pattern in the data because of the computer operations. The way to avoid this is to always read out the CCD with exactly the same spacing between operations. I have built big analog systems both ways. This is a 16 bit system. The only way I have found to make such systems work to their potential is to make sure there is no asychronous stuff around. Believe me, I no longer build systems that interrupt. I build systems that poll. If you poll you are always in control. True, you may find when you poll that you got somewhere too late. But you always know (if properly designed) that you did not get there in time. True, you can achieve the same thing with interrupts, but it is harder. Now if I could just turn off all other system functions for 40 seconds while I did a read, I might attempt some of the routes that yout describe. But I don't know how, and if I did, the operating system would not like it. At the minimum the system clock would lose counts. While I am reading 32 Mbytes in 40 seconds with the current system, there are ADC's around that would do it in 2 seconds or so. So I want to be able to transmit 32 Mbytes in 2 seconds over a 8 bit wide bus without *any* variation in timing. If you know how to do this let me know. This is why I designed my own memory. (Merle did it). Now I can run "data push" with no handshake. My memory is always ready since no one but me has access. Tom Droege Date: Fri, 16 Jan 1998 20:32:04 MET_DST From: ALAIN MAURY To: tass@wwa.com CC: maury@ocar01.obs-azur.fr Subject: Loral CCD size The chip is 2048 15 microns pixels, which is 30.72mm on a side, and 43.44 mm in the diagonal. Alain Date: Tue, 27 Jan 1998 14:14:56 -0600 From: Tom Droege Subject: Re: Mark IV control software To: tass@wwa.com OK, I guess I should write a little about how the stepping motor drives work on the Mark IV. At the moment there are 9 stepping motor drives build into the Mark IV design. Eight are general purpose, one is special for the RA drive. The general purpose stepper drives are run by a two bit register and an enable bit. The enable bit turns on the power. The two bits are the phase drive. To drive a motor, one turns it on with the enable bit, then loads a sequence of two bit codes into the register at intervals that the stepper motor can stand. The motors I use will go to about 200 steps a second from a dead start. I was able to get them to 2000 steps a second with some fancy home built hardware. At the moment, stamp code receives a command like "step forward 300 steps", and does it at a fixed rate. There is also a command of step until you reach a limit. In either case, the rate is determined by code in the stamp. It would not be too hard to program in a ramp up. Ramp down is no problem. Eventually one might run out of room in the stamp with too fancy a step program. I envision commands like "step to forward limit","step n steps forward", "step n steps back", "step to backward limit". These should solve most moves. If you keep track in the PC of where you are, then this should be enough for any move. One should only have to move to a limit on turn on. The RA stepper drive is different. It is step time critical. It will be driven by a precision VCO. We will measure the temperature at the VCO so that it will be possible to temperature compensate it. The VCO drives through a 7 stage binary count down, with selection at each stage by a register bit. There is a bit that controls the direction, and a bit to turn on the power. There is a DAC that will provide a minor trim, and a POT that provides a major trim. The binary count down will be used to select to within a factor of two of the correct sideral rate. The pot will be used to set the rate, and the DAC will be used to trim it withing 0.01% or so. Any temperature compensation will be done by program control. There is also a direct path where the Stamp can pulse the RA drive to slew it, and to home it to a limit switch. I envision stamp commands like "start sideral drive", "stop sideral drive", "backup n steps", "forward n steps", etc.. Again there will be limit switches to detect end points. I have found the limit switches to be good to 0.001". This is about 10" of arc for the RA drive. We will half step the RA drive for about 5" of arc per step. This means that the normal (sideral rate) for the stepper is 3 steps per second. If we can only slew the motor at 200 steps per second, then that is a 3/200 forward to back ratio. If we track for an hour, it will take 54 seconds to get back to the starting point. This is not so bad since it takes 40 seconds to read out an exposure. So most rewinds can take place while the CCD is being read out. For the declination drive, I have only picked part of the gear train. It will probably go a few minutes per step. This is negotiable. Can anyone think of a reason to step more accurately? The slower one steps the slower one slews. So Chris, I think everything is built in that you might want. The only question is whether or not there is enough room in the stamp to do the ramp up and ramp down schemes. I am using cheap motors, so they could be improved. The Hurst SLS which you can find in the Allied Catalog. I will think about where I could put a header, but don't see why everything you want to do can't be done now. The last code used about half the space in the stamp, and that was with a 4 bit bus which caused a lot of program problems. The new 8 bit bus is more efficient. Tom Droege Date: Tue, 27 Jan 1998 15:17:39 -0600 From: Tom Droege Subject: Mark IV Stamp Code To: tass@wwa.com At 10:01 AM 1/27/98 -0600, Chris wrote: (snip) >> >>I also wrote that I couldn't figure out how to do an exposure. >>I had expected commands to clear charge from the CCD and start >>a readout. I'd also like to know how data gets stuffed inti the >>memory board. I gues the details of that don't mater for now. The only way I can see to clear the CCD is to read it out. You probably have to do it several times at the start. This seems to be a common problem for CCDs. I hear grumbling from the Sloan worker bees about this. Each read out takes 40 seconds. You can determine when it is done by polling on the memory done bit. Or later an interrupt. If it works. One does a read out by sending a message to the stamp that says "read out the CCD". All the stamp does, is send a single pulse to the read out circuitry. It is off and running for the next 40 seconds. To open or close the shutter, one sends a command to the stamp. It then sends out a pulse train to the model airplane servo for the next several hundred milliseconds, and then returns a message to the PC when it is done. The PC will know that the shutter operation is complete when it receives this message. Note that all serial messages to the stamp work the same way. When the return is received you know the operation is done. But "done" may mean "started", or whatever. But a command like "move in RA to the limit" won't send back the return message until complete the way I have the stamp coded. A minimum stamp serial message takes about .3 seconds. Don't see why it takes this long, but if I don't put in a minimum pause the PC will hang. Note that a command like "move in RA to the limit" must have the usual time out checks in case of a mechanical hang. > >>In general I don't see much I'd change. I think I'd add some >>way to send informative error messages back to the PC. and >>maybe a power on test of some kind. I have downloaded the STAMP >>documentation from the Parallax web site, a lot of reading. The way I have it set up, every string sent to the stamp gets back either the same string, or one with information coded into it. If the stamp can detect an error, there is a place to put it. Note that I have built in a "dead man". The stamp must receive at least a dummy message at intervals or else it restarts itself. This keeps it watching for commands from the PC. It will send a message to the PC saying "I have not heard from you lately" if it does not hear from the PC. This means that loops like "step to a limit" have to have code that limits how many steps are taken or a hang is possible. Back to "I also wrote that I couldn't figure out how to do an exposure." One has to be intelligent about overlaping read out with moving the RA drive back to the starting point, opening and closing the shutter, etc.. I have tried to set up all of these things so the desired simultaneous operations are possible. Once the read out is started by a single pulse from the stamp, all (up to ) four CCDs are read out and stuffed into the memory. The stuffing is interleaved by high and low bytes and for the 4 CCDs. Not pretty, but a simple loop will unscramble it. The bytes are stuffed in starting from memory location zero (reset). You can only start stuffing from zero. (Well, if you don't reset it will stuff from where you left off.) To read out, you reset and start reading bytes from zero. You cannot set the memory address register to an arbitrary value. No. You can't do it. OK enough already. Tom Droege Date: Tue, 27 Jan 1998 16:19:51 -0600 From: Tom Droege Subject: Re: arrrghhhh ueing To: tass@wwa.com, ALAIN MAURY , pbreed@pop.nh.ultranet.com Reply to Paul Breed and Alain Maury, Well, when I started this project I looked for something like the AD9832 (thank you Paul). I did not find anything I wanted to learn about. Too complicated at the time. The AD9832 is not a bed of roses to an analog guy. The stamp could probably load it, and it is a potentially easy product to use. But looking at page 12 of the data sheet, I see that it requires some work just to turn it on. It also comes in a package that I am not prepared to handle. There are a few hundred "items" in the Mark IV design. I have to keep each one as simple as possible. "Simple" means I know about it and understand it. This takes some time for each item I am using. I have these nice little stepping motor drivers. Now they work great. But I burned up a bunch before I learned how to make them work great. Digital DDS devices are not all they appear. In the end they are only as good as the crystal. A typical crystal is only good to about 3PPM/C. The device I am using is 50PPM/C. I think I would want to temperature compensate either one. I understand temperature compensation, and can probably hold something that I understand to <0.01%. This is all I need. But I might be using the AD9832 had it been available a year or so ago when I started the Mark IV design. A lot of people keep up with all the current devices but never get anything out the door. The trick (I think) is to just set some date and go with what you have in hand then. Tom Date: Wed, 28 Jan 1998 09:30:44 -0600 To: tass@wwa.com From: Tom Droege Subject: Re: CCD Charge clearring, is it required? Reading out the CCD clears it, so the clear operation is something you only do at the start of the evenings runs, or if you have been off for a while for some reason. The longer you are off, the more charge accumulates. When things get really saturated, then you have to clear several times. The charge ends up in funny places on the chip and it takes a while to migrate to where it can be cleared. At least this is what I have found experimentally. Experts can comment. This is one great advantage of the drift scan operation over picture mode. After a few drift scans, the charge conditions settle down, and the constant scanning at constant intervals means you get very repeatable line to line results. I give up drift scanning on the Mark IVs with reluctance. My view is that in picture mode, you want to take pictures at very regular intervals if you want comparable results. Tom Droege To: tass@wwa.com Subject: Re: CCD Charge clearing, is it required? Date: Wed, 28 Jan 98 08:32:37 -0700 From: aah@nofs.navy.mil Chris asked if 40 seconds was unreasonable for clearing the CCD (which it is), and Roland asked if you could just do vertical transfers with one serial readout at the end. Usually, to clear a CCD of charge, you need to transfer all charge to the reset node on the CCD. The usual way is to do several vertical shifts (like binning), and then do a binned serial readout with reset enabled and no ADC convert. I think 1000 vertical transfers is a little excessive, as the trick is to not saturate the serial register 'pixels' terribly. I usually do tens of vertical shifts plus tens of serial bins for a 2048 CCD, and then do 1-3 of these 'wipe' operations before an actual exposure. For normal images, where there are just a few leftover remnants of stars to remove, this procedure works well. This should just be an extra clocking scheme to stick in the EPROM -- right, Tom? The harder one to implement is what is commonly referred to as an erase cycle, used to clear the chip of any residual images. Arne Date: Thu, 29 Jan 1998 22:34:21 -0600 To: tass@wwa.com, Chris Albertson From: Tom Droege Subject: Re: Clear-Sky/software and motion controllers My stepper motor drivers cost me about $4 to add to a board. I am using the UC3717 driver. Takes two. Cheap. I bought 100 a long time ago and am still working on that batch. Tom Droege Date: Fri, 30 Jan 1998 11:08:17 -0600 To: tass@wwa.com From: Tom Droege Subject: Re: CCD Charge clearing, is it required? > [from Chris Albertson] > >Here is what we can do to perform the "expose" command: > > >Option 1, the Mk IV has no erase mode: > > 0) When the memory board sends the interrupt, signaling that > the CCD has been read out we start a timer running. > It counts in seconds. > > 1) When we get an expose command we check if the shutter is open. > if open we send an error back and quit. > > 2) So now we know the shutter is closed. First check the timer. > if the timer has a large value or if it is not running then > we do a read out operation and clear the timer. This takes 40 sec. > > 3) open the shutter. start an exposure timer. > > 4) when exposure timer expires we close shutter and send the > pulse to signal a CCD readout. > > 5) When memory board is full (interrupt happens) do step zero > and read out the memory to a disk file. > > This will let us do back to back exposures but will force a > clear operation if there has been some time between exposures. > >Option 2, there is an erase mode. > > This is easy. We just do an erase every time before opening > the shutter. We need not care how long it has been sense the > last time we took an exposure. > >The question I have is will bright stars leave their imprint on >the CCD from one frame to the next? I think it may be a matter >of degree. I remember the trail effect on the Mk III. Saturated >stars leave trails. Apparently some charge gets left behind >when you row shift if the star is bright enough. >-- > --Chris Albertson home: chrisa@wavenet.com > Redondo Beach, California work: chris@topdog.logicon.com Chris and all, At 10:21 PM 1/29/98 -0800, you wrote: >Thanks for the comments. I think I know a bit more then I >did a few days ago. > >It sounds like charge clearing is required if the CCD has been >sitting around for a while. How long is "a while" and does it >need to be cleared once or several times. A while is the time it takes to accumulate charge. This can be from leakage current while warm, from light, or even from cosmic rays. > >I also hear that CCDs can be cleared quickly with some binning >tricks. I think that once the charge has migrated all over the chip, that a fast clear no longer works. It just takes a while - probably minutes - to get it to a stable state. You might as well do standard 40 second read operations as anything else during this time. Time is what it takes ones you have saturated the chip. For normal exposures, though, one read clears everything. It is only necessary to have a fixed time between the end of a read and the start of the following exposure to assure a constant dark background. There is room in the prom for a second operation. This could be a fast clear. But I can think of better uses for it. Say a read out of only the 500 x 500 center of the chip for a faster focus sequence. This would only take 2.5 seconds or so. Hmmmm! Come to think of it, a fast read for focus program would also be a fast clear. So possibly these two programs would provide everything we need. OK, below you are thinking like an "interrupt" programmer. In all the below is the assumption that you don't know what the sequence might be. Well this is much tougher than running in "schedule" mode where you schedule an all night sequence and only check as you go along that you are keeping to your schedule. My preference would be to run in "schedule" mode. Here you set up an all night schedule with known intervals between the end of one exposure and read out and the start of the next. This makes all exposures have the same dark background, and the same read out errors. It is then only necessary to have one clock interrupt at which you "poll" your task list and see what it to be done. I call this type of programming "poll" driven as opposed to "interrupt" driven. I know that interrupt driven code is most popular with programmers. The advantage of poll driven programming is that you never fail deep into an interrupt structure where it can be very hard to unscramble what went wrong. With polling, you just check you list at each interrupt. Then you know immediately - woops! - I got to item 7 too late - fail. You always know where you failed and why. But I admit my experience on this goes back to 1968. Several years of interrupt driven code for our PDP-8 communications processors faild to produce robust code. When the code was rewritten for polling, this only took a few months and immediately produced bullet proof code. This was back though when our high speed trunk lines were 9600 baud, and we were running ASR-35s. OK, Chris, you all will do what you want. I will write polling code in QBasic for the prototypes. Then you will get to write something better. I figure the way I have the system designed, I will be able to write everything needed to run a stand alone station in QBasic. I can even imagine having the QBasic program read a file at intervals to pick up commands put there by an Ethernet link. Beyond that, running some sort of communication program to put the stuff in the file, is beyond my abilities. But I can imagine running a "stock" program that allows me to telnet to load the file from a remote location. Wow! 200,000 lines of code to do this. I can't imagine how so much code was written. In answer to the bright star question below, I think it will be hard for much charge from a bright star to be left behind. This could happen if the star is at the very top of the frame (last line to be read out) and some charge from it has leaked to the adjoining substrate. The trails from a saturated star seen in the present data are a different effect. A saturated pixel leaks to the adjoining pixels. All this charge is removed on a frame read out. Tom Droege Date: Mon, 02 Feb 1998 22:57:46 -0600 To: tass@wwa.com From: Tom Droege Subject: Progress I have been working away. Friday I sent the camera head board out for printed circuits. I have been working on the main logic board. I have it divided up into three major parts, the Stamp controller, the scanner, and the ADC section. It will be one 10" x 16" printed circuit board. It is now complete, but I am still checking and adding things like grounds around the edge, etc.. There is one more board to do and it is half done. It contains the miscellaneous stuff. One section contains the TEC drivers and it is completed. The second section contains all the motor drivers. I have not started it yet. It is not complex but there is a lot of little things. The electronics will take up about 10" x 26" of board space. Two big boards. Merle is working on revisions to the memory board. I think I have decided to mount the boards directly on the telescopes. With four telescopes in a row, there is a lot of room. This will make for very short leads from the camera heads to the electronics, and I like that. But it does put the electronics out in the open. It will also reduce the number of heavy cables that must come off the moving mount. I don't think this will be a problem but I might as well limit the wiring if I can. This is always a problem for big telescopes. I figure the electronics can stand any weather that the lenses can stand. I feel good about the progress. A few weeks and I will be testing. (and writing code). Meanwhile, I have been getting the first Mark III data in what seems like months. Not much since mid November. One or two days and that was low quality data. Tom Droege Date: Tue, 10 Feb 1998 16:43:06 -0600 From: Tom Droege Subject: Re: CB2xx RT-linux driver To: tass@wwa.com, Chris Albertson I am quite confused about what is being discussed here. Not up to the software talk. Just so you can all think about it, here is how the Mark IV works. 1) There is a program to run which is time sensitive. It worries about opening and closing the shutter, and moving the camera to the proper position for the next exposure. At the end of an exposure, it sends a single command (after closing the shutter) to the camera electronics which causes the camera to dump it's image into the special memory card that is resident in the PC. Once this process is started, the program can go about getting ready for the next exposure. Before opening the shutter, it must make sure that the read out process is done. It determines this by checking a status register. Once the status comes up, the next exposure can be started with it's length determined by your favorite timing scheme. Before starting the next dump into the memory card, the program must determine that the last unload has completed. 2) A second process does not (particularly) have to know about time. It just has to know that there is an event in memory. When it finds an event in memory it must unload it a byte at a time. The data from the four cameras will be 0 Hi Byte, 1 Hi Byte, 2 Hi Byte, 3 Hi Byte, 0 Lo Byte, ... working through the pixels, so some formatting is required during unload (or later). There is no multi-event buffering. It is not possible to read out a particular location in memory other than by setting the address register to 0 and reading bytes until you get to the one you want. It is expected that this process will read out the data and put it somewhere. It will then clear the status bit that was set by the first process loading the memory. The first process can know this by checking the status bit. Some useful numbers. It takes 40 seconds to read out 1-4 cameras. 4 cameras just produce more data. There is an ADC for each camera, and one can transmit bytes much faster than the ADC can convert. A typical exposure will take 200 to 500 seconds. During the 40 second read out time, the camera has to be repositioned. Plenty of time for this. During the exposure, say 200 seconds, one must read out up to 32 MBytes and put it somewhere. I think this should not be too hard with a not to old computer. Somewhere, I think, can be another computer over a cheap Ethernet link. I see no reason why we should not use a whole computer just to mind the camera, read out the data, and send it to another computer where you do serious things. A quad Mark IV will cost $10-15,000 to build and would have a commercial cost of order $100,000.00 Why not devote a computer to this task and not try to design stuff at great cost that can be bought for $29.95 +last year's computer? Sorry if I am confused about what the problem is. Tom Droege Date: Wed, 11 Feb 1998 13:53:27 -0600 From: Tom Droege Subject: Mark IV Software To: tass@wwa.com I have been thinking about software for the Mark IV. It is not too soon to start thinking about specifications and to start writing code. I would like to write it in modules, and pass out the modules for work to a number of people. If a lot of you want to work, we might even have several versions of each module. This all depends on setting up a group of well defined tasks, and spelling out in detail the calling procedure between tasks. I would like to start the process by putting up a first pass at a task list. Since I don't know much about software it will surely be wrong. The rest of you can revise the list and when we get it in final form, I would like to make it a technical note. Module 1 A command structure for speaking to a camera installation over the internet or some other communications media. Module 2 PC code that interprets the command structure. Module 3 Code that accepts the command structure and sets up the appropriate schedule of operations. Module 4 Code that sends serial commands to the Stamp, and has appropriate checks and tests. Module 5 Stamp code that performs camera operations. This code interacts with Module 6 as the memory module is filled and emptied. Module 6 Unloads the memory module and passes the result to the first level of event storage. Module 7 FITS format for events Module 8 On line display Module 9 Moves data to the processing storage level. Module 10 Star list processing Module 11 Data Base Processing Module 12 Data Base Module 13 Data Base Communication Language Module 14 Data Base Display Module 15 Camera test code Module 16 System test code OK, this looks like a big list. It is certainly not complete. It is indeed a big job. I will volunteer to do Module 5 and 15 as one has to understand the intimate details of the hardware to do these. Part of the list has been done at least once. I will have to write 15 as the very first task so I can debug the hardware. But I will try to write it as a documented QBasic .exe program so any of you can run it later. My idea is to define the boundaries between the modules (once we have settled on an "official" list) well enough that we can exchange a new module for an old, run standard tests, and be reasonably confident that the bugs left are of well defined types. Of course, the structure should allow adding code modules that we do not think up immediately. As part of my testing I expect to do the first 10 or so in Basic and using existing code - Star, Deep Sky, etc.. This will give the rest of you code samples of what works to do various operations. You won't want to do it the same way, but it will allow starting work before you actually have a camera. Tom Droege Date: Thu, 12 Feb 1998 14:26:01 -0600 From: Tom Droege Subject: Re: Mark IV Software To: tass@wwa.com Chris Writes: >A reasonable list but I think you have broken it up into to >many parts to soon. > >Here want I'd do: Break it up level by level into a hierarchical >structure. The idea is you define one module "the system" >next you decompose that into parts (from three to five parts) >and think about how those parts interact. Thinking about >how 16 parts interact is far to complex for us mortals to >attempt. Likely three layers is enough (snip) OK, I will try again. There are two main modules: 1) Data Collection a) Input: Some Command Language b) Output: FITS Files 2) Data Processing a) Input: FITS Files b) Output: Technical Papers At the moment I am mostly concerned with 1). Note that we are already doing 2). What we do for 2) should not change much with the Mark IV. The files just get bigger. But by the time we get there, computers will be faster and disks will be cheaper, and 2) might not be much harder than it is today. To a certain extent I have already done 1) for the Mark IV. For prototype tests, I wrote a menu program in QBasic. It has functions like "Home the RA Carriage", "Move n steps W", "Open Shutter", "Pause n seconds", etc.. I can then write a script in these functions that does everything necessary to make an exposure. This gets me a raw binary file. I then read this file into Mike Gutzwiller's "Deep Sky" which lets me do such things, and then I have it write out a FITS file. With very little work, I can imagine writing QBasic code that runs the camera for a whole evening and fills the disk full of binary files. I can then imagine talking Mike into writing the necessary patch to read all the binary files and convert them to FITS. If I can do it by hand, then it should not be too hard to automate the process. So 1) is almost done. 2) is being debugged as I write by Chris, Michael, and Co. What I am really after is a careful definition of the pieces of this process so that it can be improved a small bit at a time. We already have a great start on this by defining that FITS format is the way we exchange data between 1) and 2). Possibly we need do little more for 1). This is not supposed to be a general purpose telescope where many people at arbitrary locations can send in an arbitrary programs for the telescope to process, scheduld and prioritize. It is mostly only "who is going to run the standard program tonight and respond to error messages". This does not sound too complicated to me. OK, I know it is more complicated. But the only way we can take on such a big job it to delude ourselves that it is easy. ;^) Tom Droege