Camera sensors/modules - probably stupid question

[RogerRowland]

I sort of feel that I should know this, but can't seem to get my head straight.

I'm looking for a cheap camera module to use in a project (hobby, not commercial) for making timelapse recordings. I want at least HD resolution when I build the individual images into a video, so I'm looking for 1920x1080 as a minimum.

Although I can find numerous modules that provide 30fps HD video (mainly Omnivision based like OV2710, OV5642, etc.), and I could (and have) adapt one of these to single-frame use, I feel like there should be something that just takes a snapshot and is therefore a) cheaper and b) easier to interface. I can't find anything though. Maybe the search terms bring up too much of the video cameras because that's what's popular. Am I being naive to think that the technology for grabbing a still image is "easier" than video, or is there just no demand for such things?

Bewlidered and seeking opinions/advice.

[Kilrah]

I feel like there should be something that just takes a snapshot and is therefore a) cheaper and b) easier to interface.

There were some in the past, but I've never seen more than VGA resolutions.

https://www.sparkfun.com/products/retired/10061
https://www.sparkfun.com/products/retired/9334
https://www.adafruit.com/product/397
https://www.adafruit.com/products/1386

Am I being naive to think that the technology for grabbing a still image is "easier" than video

Yep, it's basically more complicated since what sensors do is just push out pixel data, to make a still and provide it through a simpler interface there would need to be a processor to do the job.
Would certainly not be cheaper than ubiquitous video-capable parts that are made in millions for the smartphone industry.

[RogerRowland]

There were some in the past, but I've never seen more than VGA resolutions.

Ahhh, ok, then I'm not going to bother looking any further, I'll just press on with what I've already got laying around - now that you've mentioned some, I do seem to remember those serial JPG camera modules from a while back.

[JacquesBBB]

Maybe a raspberry pi 3 with their new camera module il a good choice:

Very easy to interface , meets your specs and better.
http://uk.rs-online.com/web/generalDisplay.html?id=raspberrypi

[bktemp]

A raspberry pi is probably the easiest and cheapest solution if you need full control over the capture settings, because all the low level stuff is already available. You only need to add a simple script or your own code to control the capture interface.
If you just want to make timelaps recordings, many cheap action cams also support that.

Today almost all sensors use either 8/10/12bit parallel data or MIPI. Unless you have a powerful microcontroller with a hardware camera interface you need a FPGA to handle the high data rate.
OV5642 is a 5MP camera and seems to have a builtin JPEG encoder, but you still need to be able to capture the highspeed parallel data.

[bitslice]

Buy a cheap camera,
have a timer circuit press the shutter button every 10 seconds.

It's often cheaper to re-purpose a product than to build something yourself.

[RogerRowland]

Thanks all, I think I have my answers.

For context, the main purpose of doing this is not the end result (timelapse), I'm still learning and extending my skills and wanted to have a slightly more challenging task to design. I've mainly been using 8-bit PICs but have now moved to PIC32 and have used the techniques that mikeselectricstuff demonstrated to get a PIC32 talking to an OV7670 using DMA and PSP to just extract low-res monochrome images. More recently, I've acquired a handful of ARM devboards, a couple of Cortex M3 and an M4, which gives me more speed and an opportunity - I thought - to try something similar with a higher resolution camera and/or full colour without jumping straight up to MIPI, which is a step too far right now. The only thing bothering me was the lack of a suitable camera module, everything 1080P seems to come already with USB interface and costing around £30.

So, no RaspPi, no GoPro, because it's not the application that's important and after 39 years of writing software I'm a bit fed up just coding. So I just contrived a project that combined the areas where I wanted to develop more low level experience - possibly a bad choice, but ... coordinating hardware peripherals on a micro and tackling circuit designs and PCB layouts is where I'm at right now.

Anyway, thanks for all the replies - I've seen some 720P modules that may be a better halfway house, so I'll see how things go from there.

[Richard Crowley]

There are open-source (free) software for controlling many popular DSLRs. Including some DSLRs that are probably less expensive than 2K camera modules. Not to mention much better picture quality, better selection of lenses (wide, tele, etc.) and less fooling around with the hardware, etc. etc.  Sometimes using a pre-engineered mass-market consumer product (like a cheap DSLR) is the better choice.

[RogerRowland]

There are open-source (free) software for controlling many popular DSLRs. Including some DSLRs that are probably less expensive than 2K camera modules. Not to mention much better picture quality, better selection of lenses (wide, tele, etc.) and less fooling around with the hardware, etc. etc.  Sometimes using a pre-engineered mass-market consumer product (like a cheap DSLR) is the better choice.

Yes, I guess I should have explained the context up front - see my previous post, which must have crossed yours - the point is not that I want or need a timelapse camera, the point is that I do want to be "fooling around with the hardware" ...

[bktemp]

I've mainly been using 8-bit PICs but have now moved to PIC32 and have used the techniques that mikeselectricstuff demonstrated to get a PIC32 talking to an OV7670 using DMA and PSP to just extract low-res monochrome images. More recently, I've acquired a handful of ARM devboards, a couple of Cortex M3 and an M4, which gives me more speed and an opportunity - I thought - to try something similar with a higher resolution camera and/or full colour without jumping straight up to MIPI, which is a step too far right now. The only thing bothering me was the lack of a suitable camera module, everything 1080P seems to come already with USB interface and costing around £30.

PIC32 work upto a couple of MHz, because the DMA can't handle more than 10MHz continous data stream reliably. Many STM32F4 have a DCMI, a camera interface up to 54MHz pixel clock.
One problem with large images is simply the amount of image data: A 1920x1080 image has around 2Mpixels, that's 4Mbytes YUV data. Because most image sensors don't have a full frame memory, they use rolling shutter for reading the image slowly while transmitting the data. At 25MHz pixel clock 4Mbytes take at least 166ms. That is only useable for still images with no moving objects.
OV5642 supports up to 96MHz pixel clock for 5Mpixels, but it can be reduced to 48MHz, perfectly matching STM32's DCMI. Especially when used in JPEG mode that should be fast enough to quickly read out the images.

[RogerRowland]

PIC32 work upto a couple of MHz, because the DMA can't handle more than 10MHz continous data stream reliably. Many STM32F4 have a DCMI, a camera interface up to 54MHz pixel clock.
One problem with large images is simply the amount of image data: A 1920x1080 image has around 2Mpixels, that's 4Mbytes YUV data. Because most image sensors don't have a full frame memory, they use rolling shutter for reading the image slowly while transmitting the data. At 25MHz pixel clock 4Mbytes take at least 166ms. That is only useable for still images with no moving objects.
OV5642 supports up to 96MHz pixel clock for 5Mpixels, but it can be reduced to 48MHz, perfectly matching STM32's DCMI. Especially when used in JPEG mode that should be fast enough to quickly read out the images.

That's useful, thanks - I'm using a 50MHz PIC, which I've overclocked to 60MHz without problems (well, at least once I got it off the breadboard onto a PCB) and I'm running the OV7670 clock at 15MHz, which allows me to comfortably grab the luminance channel over DMA into RAM and then out over UART at 1Mbps to the PC. Eventually, this will drive a low-res array of 8x8 LED matrices, which is the other part of the project, and is already done apart from some tweaking.

The annoying thing about these camera sensors - although understandable when you think about it - is that reducing the resolution doesn't magically give you more time to grab the pixels, you just end up waiting longer between frames. Following your comments, I think I'll add an STM32F4 dev board to my collection and see what I can do. I already have an STM32L Discovery like Dave recently previewed, along with a couple of MSP432 Launchpads (which may be fast enough?) and a Cypress PSoc5LP, so it may be useful to compare the development environments as well as the hardware. I've no particular need for low power, but it seems that it's very popular at the moment and these particular dev boards can be had for pennies.

[bktemp]

Following your comments, I think I'll add an STM32F4 dev board to my collection and see what I can do. I already have an STM32L Discovery like Dave recently previewed, along with a couple of MSP432 Launchpads (which may be fast enough?) and a Cypress PSoc5LP, so it may be useful to compare the development environments as well as the hardware. I've no particular need for low power, but it seems that it's very popular at the moment and these particular dev boards can be had for pennies.

The big advantage of STM32F4 (and STM32F7) compared to other similar powerful controllers is the dedicated camera interface and the SDRAM controller. Using the DCMI it can capture the image and write it into external memory (5Mpixel -> 10Mbyte uncompressed YUV data!) using DMA. PIC32+PMP works fine for low res images, but having a dedicated camera interface and a large memory is the only useable solution for large Mpixel images.
If you buy a dev board, it should have a large SDRAM and all of the required DCMI pins (PCLK, HSYNC, VSYNC, D0-7) should be available. Unfortunately DCMI seems to have a low priority on most dev boards, so you probably need to make your own board.

[amyk]

Am I being naive to think that the technology for grabbing a still image is "easier" than video, or is there just no demand for such things?

A camera sensor is basically arranged as a very long dynamic shift register, so it needs a minimum frequency to keep operating. This is so they don't need any additional memory on-die. Any sort of "snapshot" mode is basically just gating the internal scanning clock.

In other words, there's essentially no difference between continuous streaming images and taking a single one in terms of die complexity. The "it can do video too" (even if at a very low framerate) also makes for another bullet point in the spec, so it doesn't really make sense to not have video capability --- and you can get video from any sensor by just continuously reading frames from it.

A lot of the Omnivision sensors can be slowed down below their normal pixel clock rate, here's someone running an OV7670 at a 1MHz pixel clock using a regular Arduino:

http://forum.arduino.cc/index.php?topic=159557.0

...and the lowest I've found, an OV6620 at 69.25KHz pixel clock:

http://www.robozes.com/inaki/dproject/report.pdf

[bktemp]

In addition to that it is often necessary to read out and analyse images before taking the actual snapshot for doing stuff like white balance and exposure control (if it is not done automatically inside the sensor).
And often you also want a preview image.

[RogerRowland]

In addition to that it is often necessary to read out and analyse images before taking the actual snapshot for doing stuff like white balance and exposure control (if it is not done automatically inside the sensor).
And often you also want a preview image.

Of course, obvious now ... I guess also auto-focus, assuming that's all part of the sensor and not bolted on elsewhere?

[bktemp]

Unfortunally there are almost no datasheets for camera sensors, so I don't know if modern sensors have a build in focus controller or if it is done using the main SoC.
I have seen older sensors with buildin autofocus, but my guess would be in modern sensors it is done in the SoC because of the advanced autofocus functions like face detection.