OpenSource CCD Camera Project (collaboration)

[fluidhomefront]

Hi Cath,

I'm interested in your project (http://stargazerslou...e-sensor-chips/). For the last few months I've been working on something similar and would be interested in some collaboration.

I'd like to see a truly open-source camera available for amateur astronomers. One way that we could collaborate would be to have rule that we only use Open-Source software (e.g. gEDA for schematics, Ubuntu for development, Arduino for firmware). Designs and software could be kept openly on Google Code or an open DropBox/Google Drive site. I find it frustrating how previous publicly developed cameras have ended up commercial or became rapidly out-dated. I think the spirit of stellafane fits well with the modern open-source movement.

I'm quite inspired by the Magellan camera (http://instrumentati...u/ccd/gcam.html) but I think Analog have come up with some better/cheaper op-amps since that design. I like the Magellan's signal processing circuitry and I take their point about doing all the signal processing at a high voltage (dual 10V). But then it sounds like the Artemis cameras opted for a simpler digital-only signal processing approach. I'm not sure about the merits of the hardware based double-sampling integration vs. taking multiple samples with a fast ADC but hope to find out with a prototype. The Genesis camera (http://www.eso.org/s...isCCDCamera.pdf) also seems interesting but dated.

My approach so far is to use a 72MHz version of the Arduino (MapleLeaf) to produce the various clocks for the sensor and to read from a 16bit ADC. It would be even more fun to use a Raspberry Pi but I'm perturbed by their lack of availability.

The Maple leaf has two 1MSPS, 12bit ADCs on board which could be used for planetary imaging. I'll use a cheap 100kBPS 16bit ADC for slow read-out deep-sky imaging. Clocking will be handled by fast, analog multiplexors allowing three level vertical clocks and fast settling op-amps to drive the high capacitance loads from the CCD. I'm going to control important voltage levels such as the CCD amp-power, substrate-clock and the low-level for the vertical clocks using a digital pots feeding fast settling op-amps with sufficient current rating. For starters, I'll throw the data out at an FT232R USB2 chip but I see there might be a need to buffer frames for high speed capture.

The other thing that would be useful to share would be reading lists. I've kept copies of the most relavent internet references I've found and I have several books out on CCD imaging/sensors.

I'm aiming for a prototype that can use a Sony ICX429ALL (extracted from CCTV cameras on eBay), or an ICX282 (available as a spare for Sony video cameras). It would be nice to be able to just plug in a full frame Kodak sensor and update the firmware.

Ian

[Cath]

Hi Ian

Our idea was to go well over the 640*480 sized sensors as it can be somewhat limiting if you want some decent resolution (assuming the seeing allows it). And also to go with most likely an FPGA sitting between a good sensor and at least a Cortex M4. An FPGA provides you with a lot of parallel hardware handing of the sensor data which a CPU can't really do if you need say >= 25FPS.

A Cortex M4 STM32F407 gives you 3 * 12-bit 2.7 MSPS ADCs which provides upto 24 ADC input channels or a 7.2 MSPS ADC in triple interleaved mode, although 12-bit sampling is still to limiting so an external 16-bit high SNR ADC would be used on the FPGA (or CPU if no FPGA is used) if analogue sampling of the sensor is required.

I was certainly thinking of the CCD/CMOS sensor board being upgradable, but you'd no doubt eventually need some decent processing power on the main board to handle frame buffering and any basic DSP computations you'd like the raw image data to be passed through and the packet handling when transfering (in real time) all the data back to any connected PC via whatever link is used (Giga bit lan etc).

A couple of DSP functions that would be nice would be say pixel linearization to allow magnitude measurements and white balance to get accurate colour spectrum. Then theirs bias subtraction, hot pixel management, binning etc - all in real time.

I'd also want things like temperature and humidity monitoring, serial output to control the scope position, motorised focus control output etc. This would allow the user to have a single giga-bit lan connection (or slower wifi) to control EVERYTHING via a single connection - I hate wires everywhere !

But anyway, a simple 752 × 582 super HAD sensor (ICX429ALL) and a Cortex M3/M4 CPU would be an interesting place to start. It would be a very simple system to start with, certainly out perform all those SPC900's and any other webcam usage people out there are using.

The Atmel CPU's used on the Arduino boards are a bit limiting really don't you think?

Some of the projects I've worked on tend to be cutting edge that requires some moderately serious hardware processing abilities - the area of software/hardware design that I prefer.

I wonder which cameras you've found on ebay that contain the Sony ICX429ALL?

[fluidhomefront]

It sounds like we may be coming at this with different budgets and levels of sophistication in mind I'm looking at the niche just a step up from hacking web-cams with budgets around £200 to £300 for parts and £200 for tools. How much do you expect your system to cost? Is your motivation to produce a research grade camera or a teaching/access-to-science tool?

I'm interested in multi-frame deconvolution techniques and ways to get as much resolution per dollar as possible. I'd like to work on signal-to-noise-per-arcsend-per-dollar or some such measure.

[Cath]

It sounds like we may be coming at this with different budgets and levels of sophistication in mind

I'm looking at the niche just a step up from hacking web-cams with budgets around £200 to £300 for parts and £200 for tools. How much do you expect your system to cost?

I have no budget lol, it's just that the design work I do tends to be high performance rather than make-do kind of design. If I'm designing something I'm one of those people that go for performance/quality right from the start - if I can.

Is your motivation to produce a research grade camera or a teaching/access-to-science tool?

Not really, just like to do things as best that can be done with what's available. The thought of having a sensor up front and not being able to use it to the full seems a waste really, so just wanted to back it up with enough processing ability to get the best out of it.

A camera that learns and remembers how to calibrate out bias and pixel linearization according to say things like temperature would be cool I think.

Having direct sensor cooling would be a must I think too.

I'm interested in multi-frame deconvolution techniques and ways to get as much resolution per dollar as possible. I'd like to work on signal-to-noise-per-arcsend-per-dollar or some such measure.

Presume your thinking about handing those kinds of things over to a PC?

[fluidhomefront]

>> I wonder which cameras you've found on ebay that contain the Sony ICX429ALL?

The "New 1/2" 600TVL B/W Sony CCD Extreme High Resolution Board Camera CCTV" item on ebay seemed particularly good value a few months ago. I notice the price has gradually ramped up everytime I bought one but I think "buyafortune123" might let you have one for £20 if you ask nicely.

Ian

[Cath]

The "New 1/2" 600TVL B/W Sony CCD Extreme High Resolution Board Camera CCTV" item on ebay seemed particularly good value a few months ago. I notice the price has gradually ramped up everytime I bought one but I think "buyafortune123" might let you have one for £20 if you ask nicely.

I'd be very surprised if they let me have a board camera for £20 when they are asking £44 for it. I could make an offer I spose.

[fluidhomefront]

So far I've done all the image processing on a desktop computer after getting the raw frames in from the cold. A lot of the more sophisticated techniques require serious processing power and over-night number crunching. More to the point, I'd rather program image processing techniques in a high level language like Python or MATLAB than low-level C.

I very much respect your approach of getting it right first time and I'm going to think about the FPGA route. I agree it would be nice to have as much on-board processing capability as possible. I'm not sure how much cost an FPGA adds to the system but I see there are open-source tools for FPGA programming. I'm also concerned that an FPGA would put other people off hacking the camera because its a lot more to learn.

The way people have jumped on the Raspberry Pi and the fact its going to be in every school in country at the rate they're selling them made me think it would be an accessible basis for a camera. A CCD camera for the Pi would go with the Pi projects ethos of inspiring school kids to take up Comp Sci and Electronic Engineering at degree level. With the Arduino: the fact that many people on this forum are using Arduino's for focusser and motor control makes me think it would be accessible. A suped-up arduino with a decent 16-bit CCD shield could be a popular way of making CCD imaging hardware open and accessible.

My ideal result would be to produce a camera system that is easy enough to understand that other people can hack it and make it their own without spending too much. To go with the hardware, I've mostly finished a Python/GUI Based image processing software (e.g. Registax but open/tidy with more sophisticated registration/stacking/deconvolution). Its on google code and called ArcSecond but I've not packaged yet.

Ian

PS: I'm not trained as an electronic engineer but did work for a couple of summers writing embedded software. I studied undergrad physics and later mathematical modelling. I work for industry making glass these days. I've built a couple of small telescopes and done my image processing all in Ubuntu/Python.

[fluidhomefront]

The first "New 1/2" 600TVL B/W Sony CCD Extreme High Resolution Board Camera CCTV" I bought cost £20. Then £30. He's ramping the price up to meet demand. It might be worth looking on alibaba or some chinese direct site to see if you can find where they are coming from. I expect he has bought a few hundred of these boards for £10 each from somewhere.

Its a nice 1/2" ExView sensor and I think there's an LX mod to be had but I want to save the sensor for this arduino shield camera instead.

[Cath]

ahhh cool

Of the astro post processing programs I've tried on the PC so far I've not really seen any that take advantage of the processing power that todays PC's offer - multi-core/multi-threading, not to mention the massive amount of DSP ability just sitting doing nothing on all those GPU's (graphics cards with lots of parallel processing ability - far more than any CPU) out there.

It seems most of the astro post processing PC software out there plods along using a single core and no GPU. I'm a big fan of C/C++ and real time processing, so haven't really ventured into Python land.

[Cath]

The first "New 1/2" 600TVL B/W Sony CCD Extreme High Resolution Board Camera CCTV" I bought cost £20. Then £30. He's ramping the price up to meet demand.

Typical

[fluidhomefront]

Peltier cooling and PSU then:

Would you put the peltier supply in the camera box? I intend to run everything off a 12V battery because mounts are usually 12V. I've gone with having the peltier supply external so I can use a linear power supply. I made the peltier supply with three regulators under op-amp control (as given in the regulators datasheet), all mounted in a metal box with a fan. I've avoided PWM for noise reasons and so have to burn up voltage as heat to control the peltier. I can adjust up to 15A of peltier power by controlling the regulators with a digital pot. Perhaps I'm being paranoid about PWM control.

I don't really want electromagnetic noise or waste heat in the camera box.

We'll need a very low noise 15V dual supply for the CCD and probably more dual supply levels for the analog electronics.

Ian

[Cath]

Peltier cooling and PSU then:

Would you put the peltier supply in the camera box? I intend to run everything off a 12V battery because mounts are usually 12V. I've gone with having the peltier supply external so I can use a linear power supply. I made the peltier supply with three regulators under op-amp control (as given in the regulators datasheet), all mounted in a metal box with a fan. I've avoided PWM for noise reasons and so have to burn up voltage as heat to control the peltier. I can adjust up to 15A of peltier power by controlling the regulators with a digital pot. Perhaps I'm being paranoid about PWM control.

I don't really want electromagnetic noise or waste heat in the camera box.

We'll need a very low noise 15V dual supply for the CCD and probably more dual supply levels for the analog electronics.

Yes PWM can be noisy, it can be a real problem. But with proper filtering it can be made OK. You just have to ensure any PCB routing takes account of ground loops, and keeping noisy tracks very short etc, and common mode filtering of both the input and output of the switched mode regulator together with screening.

But yes, analogue regulators are the cleanest form. What is sometimes done (to keep heat down and efficiency up) is to use a switched mode regulator to drop most of the voltage, then follow it with a linear regulator (dropping only a volt or so) to clean the power rail.

I guess waste heat could be used to keep the sensor etc dew free?

[pete_l]

Of the astro post processing programs I've tried on the PC so far I've not really seen any that take advantage of the processing power that todays PC's offer - multi-core/multi-threading, not to mention the massive amount of DSP ability just sitting doing nothing on all those GPU's (graphics cards with lots of parallel processing ability - far more than any CPU) out there.

Now that approach would be as radical a shift in amateur astro-photography as anything we've seen to date!

Imagine being able to stream live frame captures straight off a cooled sensor and into a PC. Then have a software stack on a GPU doing all the image calibration, noise removal, alignment, stacking and colour manipulation in real time, frame by frame and having the final result gradually appearing out of the murk directly on your monitor in front of your eyes.

[fluidhomefront]

For good noise proof registration, you've got to Fourier transform each image for Fourier-correlation. There's plenty of speed up by registering a region-of-interest rather than the whole image and then shifting the entire image once you know where to shift/rotate it to. There's also an example of how to do a Fast Fourier Transform with a GPU in Python on the PyCuda wiki. http://wiki.tiker.net/PyCuda/Examples/2DFFT. So that might save a few seconds per MPixel.

I see the Raspberry Pi can do 1GPixel/s, 24GFLOPs processing, so I imagine it could rattle off a few MPixel fourier transforms per second. If someone wanted to they could even use high-level languages to program it too.

It seems reasonable to align/register 1MPixel deep-sky images faster than they can be captured (several minutes per frame) just on a 1GHz net-book. I usually run the register/stack in parallel with the data capture to see how progress is looking. This is fine for mean-stacking but more robust stacking algorithms (e.g. median based) have to look at all the previous frames every time a new frame comes in.

Stack processing still requires all the images to be in memory first and I've found it takes a lot of time just to load them all off the disk. Unless you're going to use RAID arrays to store the images, there's not much parallel processing can do with that step.

[pete_l]

I see the Raspberry Pi can do 1GPixel/s, 24GFLOPs processing, so I imagine it could rattle off a few MPixel fourier transforms per second. If someone wanted to they could even use high-level languages to program it too.

Unfortunately the Pi isn't open source - all the GPU code is in the form of a BLOB [ ttechnical term ] and nobody yet has managed to work out the internals of it. That's holding back being able to get the Pi to do accelerated graphics - which makes it's video handling rather poor.

Once "the team" have managed to reverse engineer the GPU code, then lots of things should become possible, just not yet.

[fluidhomefront]

That's a shame. its so well marketed!

[Cath]

Hi fluidhomefront

I don't suppose you'd have any idea which CCD sensor are used in these cameras at all?

Board cam 1

Board cam 2

We have had one of these for sometime now but no idea which sensor it uses (we currently use it as a security camera).

Quite a few board cameras with sony CCD's available here.

Removing the sensors and doing a new PCB is not a problem, just no idea which sensors they tend to use.

[fluidhomefront]

The first one says it uses cxd4140 clock chip. Id get that datasheet and see what sensors are compatible. If you can get a look at the sensor you can count the pins and work out where the nc, vcc, gnd pins are and then compare with sensor datasheets.

[JamesF]

I love the idea of an open source camera project. Perhaps there's room for two -- a high end one for DSO imaging type applications and a lower-end one for cheap(ish) planetary imaging. Regardless, I wish I could do something useful to help. Unfortunately my understanding of electronics is painfully limited

James

[fluidhomefront]

Thanks for the supportive comment.

I've created a project documentation page on wikispot. I'd be grateful if anyone felt like reviewing the project outline:

http://opencamera.wikispot.org/

I'll get the rudimentary schematics and PCB up on google-code when I can.

Ian

[fluidhomefront]

Hi fluidhomefront

I don't suppose you'd have any idea which CCD sensor are used in these cameras at all?

Board cam 1

Board cam 2

We have had one of these for sometime now but no idea which sensor it uses (we currently use it as a security camera).

Quite a few board cameras with sony CCD's available here.

Removing the sensors and doing a new PCB is not a problem, just no idea which sensors they tend to use.

It sounds like the first two boards are of the ICX672/3 variety:

http://www.sony.net/Products/SC-HP/cx_news/vol61/pdf/cxd4127_4816gg.pdf

http://www.datasheetarchive.com/indexer.php?file=DSASW0044571.pdf&dir=Datasheets-SW3&keywords=ICX672&database=user-highscore#

The horizontal clock is conveniently 3.3V on these newer chips rather than 5V!

I couldn't find an actual data-sheet for them though. The pin-out looks the same as some of the older Sony chips.

http://www.sony.net/Products/SC-HP/datasheet/90203/index.html

[Cath]

It sounds like the first two boards are of the ICX672/3 variety:

http://www.sony.net/...4127_4816gg.pdf

http://www.datasheet...user-highscore#

The horizontal clock is conveniently 3.3V on these newer chips rather than 5V!

I couldn't find an actual data-sheet for them though. The pin-out looks the same as some of the older Sony chips.

http://www.sony.net/...0203/index.html

ohhh well done fluidhomefront, thank you!

I'll take a look.

It would be good if we could just replace the firmware on the camera boards and use the digital output rather than the composite video output. But I expect it would be difficult to obtain the needed development tools/info to rewrite the firmwares.

[Cath]

Perhaps there's room for two -- a high end one for DSO imaging type applications and a lower-end one for cheap(ish) planetary imaging.

Yes I was thinking that too James.

Their are plenty of cheap camera boards out there that can provide the low end CCD/CMOS sensors, and the sensors on these boards seem to be better/newer than what you tend to get in pc webcams. If Sony made the firmware dev tools available then it would make things MUCH easier, but I can't see that happening. So will have to be a case of removing the DSP chips from these camera boards and making a anew interface to them.

[fluidhomefront]

It would be good if we could just replace the firmware on the camera boards and use the digital output rather than the composite video output. But I expect it would be difficult to obtain the needed development tools/info to rewrite the firmwares.

I agree. I think there must be a reprogramming a board hack out there but its going to be very specific to each board-camera/CCTV. I wasted a few days trying to use the serial interface on one of the camera boards to talk to a DSP chip on the board. The trouble was that the board I was using had a micro-controller as well as the DSP chip and the micro-controller had to set up the DSP before it would work. The Sony data-sheet for the DSP was very helpful but I got eye-strain trying to send/receive signals to SMD pads before I got anywhere. You might have more look on a friendlier board.

[fluidhomefront]

I see therre are FPGAs in the form of an arduino shield, e.g. http://ubershield.com/

So how about a hackable arduino-shield astro-camera with one possible hack being the addition of an FPGA sheild for parallel signal processing and frame-buffering?