All Good Cameras Have a Sensor

I spent some time choosing a sensor early in the project, as much to test the feasibility of the project as anything. The CCD sensor will make or break the whole project, so as a sanity test, I decided to go ahead and do the research to choose a chip that fits the application.

The sensor of choice for this project needs to be usable in a camera system that does not include a mechanical shutter. That requirement alone narrows the field. I found that the sensors that go into your basic digital camera would not work because they need that mechanical shutter. Specifically, they need to be covered while the captured image is read out of the sensor. Yes, you can connect your DSLR camera to a telescope, but that camera body includes the mechanical shutter. But then again, newer digital cameras have video modes, so the right sensors for this project surely exist.

We also want our sensor to have an area of around 4Meg pixels. This eliminates most cheap webcam sensors. In fact, 4Meg is large even for HD video. That pretty much rules out webcam sensor chips. We are getting into the realm of scientific imaging sensors.

Fortunately, Kodak has a whole range of sensors, the Interline CCD family, that fits the bill nicely. Not only do these chips support readout while the sensor is uncovered, they have an electronic shutter that allows for precise control of integration time. The KAI-04022 in particular is the right size (4meg) and is square (2048x2048). That is a nice feature. (Square pegs fit better in round holes then do rectangular pegs.) These sensors are indeed intended for scientific imaging. Looking good.

The pixel density of the KAI-04022 is 7.4um square, which gives approximately 1.6 arc-seconds per pixel and a total of 55 arc-minutes field of view when put behind my 1000mm focal length telescope. The Dawes limit for this 120mm refractor is 0.98arc-seconds, so this strikes me as a good compromise. I can add a barlow lens if I really want to push the resolution. If I want to increase the field of view, I'll just need a shorter telescope. There are physically larger sensors in the series, but they are getting into the 8-10MPixel range. Maybe later.

The chip is able to read out pixels at around 40MPixels/second, which gives about 10 frames per second. This is plenty fast enough for a plausible focus mode. It's not fast enough for full-motion video, but that's fine for what I'm after.

And the Kodak chips are well documented, with thorough datasheets, and evaluation boards with complete schematics. That's good.

Finally, I checked with Kodak sales, and the KAI-04022 is currently in production. There are color and grayscale versions of the chip, so I have some flexibility there, and for small quantities the chips themselves can be purchased directly from Kodak for something in the range of $1,000.00. A lot of money, but within the total budget for the camera as a whole, so that's what it will be.

By the way, it turns out that many store-bought astronomy cameras in the $3000+ price range use these or similar chips as well, so that gives me some extra confidence that I'm not too far off the mark.

Broad Strokes

In my getting started post, I described the design goals for this camera. I can tell you right off that one particular requirement somewhat contradicts all the others. How does one shove all that functionality into a lightweight sensor module? That also begs the preliminary question "How light?"

The answer: as light as possible. Remember, the sensor is going to attach to the telescope far away from the balance point for the optical tube. Every gram is multiplied by the moment arm away from the center of mass, becomes a burden on tracking motors, and can therefore be a real irritation in the field. When I attach a Nikon D80 camera body to my telescope (Celestron XLT120 refractor) I practically have to remount the tube to the equatorial mount to re-balance it. Heck, even fiddling with the focus might cause the balance to be thrown out, never mind adding a barlow lens. So I'm motivated to keep it light, light, light. (Can I get it as light as an eyepiece? Probably not, but that's an interesting impossible goal.)

Fortunately, the first major design decision follows rather naturally. The whole device can be broken into two major parts: the sensor module and the processing module. The sensor module need only contain the sensor chip and the bare minimum electronics to send the signal out through a cable to the processing module. The processing module can contain all the featurisms of the camera, and can be strapped to the telescope near its center of mass. The size and weight of the sensor module can be minimized by removing functionality to the processing module.

The sensor module needs to hold very little stuff. I can probably keep it down to only the CCD sensor, a few ASIC chips (including a tiny FPGA) and the discrete parts needed to handle some non-digital bits. It should be possible to keep the sensor circuit board down to little more then twice the area of the sensor itself. The sensor chip is going to be pretty large as semiconductor devices go, so this shouldn't be much of a challenge. Keeping chip count low (and hopefully minimize the power draw) should have the added advantage of limiting the heat sources in the sensor assembly. Sensors like cold.

The processing module need not have the size/weight limits, so I can go crazy there. And crazy is where I shall go. The basis can be a Gumstix running Linux. This gets me a whole host of possibilities for free, including networking software and hardware. To that I will attach an interface board that includes the electronics needed to communicate with the sensor board. I can also include on the interface board the components needed to manage power supplies (the sensor board will likely have tricky power needs) and even interface to stepper motors. This will allow me to interface not only to the sensor board, but with mount motors.

Actually, there will probably be a third box. The battery pack will likely be something off the shelf that generates some standard voltages (DC) that the processing module interface board can convert to the voltages needed to run the whole system. I like the idea of having Li-ion power for the whole system, but adding the weight of battery cells to the processor module really is a bit over the top. So batteries get a module of their own.

So that's the very broad stroke. A sensor module will contain the CCD sensor and minimal support electronics; a processor module will contain the interesting image processing hardware/software, the interfaces to the mount, and some power supply management; and a battery pack will supply the power. Next post, I will probably discuss my choice of sensor chip.

Time to start a new project

I've come to the conclusion recently that I want a hobby project that is a little bit more physical and direct then the tools projects that I've been working on to date. And at the same time I want to combine some interests of mine: Electronics, software engineering, photography and astronomy. So I'm going to design, build and use a digital astronomy camera.

And not just any camera. Here are some design goals:

• Reasonable pixel count for the sensor (say, 4MPixels),
• Lightweight sensor module,
• Wireless and/or wired network operation,
• Focus mode,
• Support for auto-guiding, and
  
• Open source all the design files, firmware and software.
  

This is a non-trivial set of goals. I expect that the project will run me on the order of $3000 in parts and countless hours of labor. That's in line with a similar device purchased off the shelf (except for the "labor" part) so not too wacky a plan. The project may at times suffer from "Creeping Featurism", but so long as it remains open source and the price doesn't escalate too far, so be it. No managers are telling me it has to be done now, or ever. It's for fun, so I'll have fun features, gosh darn it! But I have some justification for the major features.

Reasonable Pixel Count

Well, this goes without saying, doesn't it? But I'm specifically thinking of around 4MPixels. Smaller cameras are already available for embarrassingly cheap prices, especially if you get down to the "VGA" range. People have even used low-end webcams at this level. I would like my device to be worth building, so I really think it needs a few more pixels then that. But too many pixels and the device becomes crazy expensive. The sensors for large pixel counts get pricey pretty fast. Since the design is open source, one can alter the design and substitute a larger sensor if one has the financial means. The 4MPixel sensors seem to around that sweet spot where it is worth building the thing, but it doesn't break the budget.

Lightweight Sensor Module

The sensor module attaches to a telescope in the place of an eyepiece (or in addition to the eyepiece for eyepiece projection) so it is way out there beyond the center of mass. I know that my Nikon-80 on the end of a 1 meter long telescope is enough to throw the telescope balance way out of whack. A light sensor module (much lighter then a DSLR camera body) will be easier to mount.

Wireless and/or wired network access

The ideal is to be able to access the camera via a wireless network. Not too crazy, people can access their printers that way these days. Wires on a moving telescope are a particular irritation because of potential binding. (Also, I have another motive here. I have access to some larger telescopes, where a wire to the camera could get quite long. Think 20" refractor.)

Focus mode

This is a mode where the camera makes a live full resolution display of a small region of interest. One can use this display to adjust the telescope focus on a nearby star. Getting accurate focus is a persistent problem with astrophotography, and is downright exasperating with DSLR cameras.

Support for auto-guiding

This is where the camera not only collects the light to form the image, but also provides a sense of the motion of the image. This allows computer controlled mounts to be adjusted by software to keep the target centered. Getting this feature implies some sort of microprocessor that can do image processing, and also obviously implies that the sensor exposure be collected as a stack of images.

Open source all the design files, firmware and software

Mechanical drawings, board schematics and layouts, FPGA designs, firmware and host software will use open source tools wherever reasonable version exist, and the designs will be released under GPL. Everything will be published, so that you can make a camera of your own.

Onward!

So that's my plan in general. I'm getting used to this blogging business, but I intend to try and write up my thinking and progress as a sort of journal for this project. Hopefully others will find this of interest.