Shop OBEX P1 Docs P2 Docs Learn Events
Call Phone Camera — Parallax Forums

Call Phone Camera

roboticsrobotics Posts: 90
edited 2012-01-16 22:49 in Propeller 1
Hi,

I have an application that requires a small cell phone camera that continuously feeds a display (approx 2" or larger type) to provide a real-time display. I've read previous posts which indicate that it is difficult to program and integrate a cell phone camera. Can you recommend a kit or parts list with directions to accomplish this?

In advance, thank you!

Comments

  • Duane DegnDuane Degn Posts: 10,588
    edited 2012-01-16 15:37
    Parallax's Laser Range Finder uses a cell phone camera. One problem of using this kind of camera with the Prop is the Propeller's small memory capacity.

    If you discribe what you're trying to accomplish others might have some alternative suggestions.

    Make sure a look a the machine vision portion of my index (see signature).
  • pedwardpedward Posts: 1,642
    edited 2012-01-16 15:37
    As far as cameras go, they can be fussy, but most are fairly straighforward. Here is a 640x480 camera at SparkFun: http://www.sparkfun.com/products/8667
    The data is transferred in parallel and commands are sent via I2C. That camera is neat because it can do windowing and lower resolutions, so you can get low res data out of it for the propeller to process, then save a high-res image to external storage.
  • Duane DegnDuane Degn Posts: 10,588
    edited 2012-01-16 15:43
    pedward wrote: »
    As far as cameras go, they can be fussy, but most are fairly straighforward. Here is a 640x480 camera at SparkFun: http://www.sparkfun.com/products/8667
    The data is transferred in parallel and commands are sent via I2C. That camera is neat because it can do windowing and lower resolutions, so you can get low res data out of it for the propeller to process, then save a high-res image to external storage.

    pedward,

    Have you used that SparkFun camera with the Prop (or other uC)?

    Because if you have, I'd love to find out how. I don't think it would be an easy task to use wtih the Prop.
  • pedwardpedward Posts: 1,642
    edited 2012-01-16 15:45
    I haven't used it, but I researched and read the datasheet on it back when I first saw it. It outputs RGB 5:6:5 via an 8 bit parallel port and you set all the config registers with I2C. Its seems to be fairly simple and doesn't have any funky encoding to deal with. I was thinking a 160x120 mode would be simple to work with.

    I thought I saw that Phil had done something recently with cameras? Or am I cornfused?
  • TubularTubular Posts: 4,706
    edited 2012-01-16 16:08
    Yes, Phil made a Phil made a really neat NTSC frame grabber recently. This is probably the most flexible in the long term and should be really cost effective too as you could use cheap security camera modules. Cell phone cameras are notorious for being only available for a relatively short time.

    I've used the 4d systems uCAM-TTL successfully in a commercial job. You can read a 160x120 "preview" image which can be displayed by the prop using Kye's 160x120 driver. Then when you want to save the 640x480 image the camera does the JPG compression which saves on storage memory (but the prop would struggle to decode the JPG, hence the preview mode is useful. The 640x480 compressed images were ~20kB in size, which can fit inside the Prop memory, making transmitting a single image over bluetooth, xbee, gprs etc straightforward.
  • pedwardpedward Posts: 1,642
    edited 2012-01-16 16:14
    The camera is 2 bytes per pixel and provides a clock output for each byte that is latched on the output.

    The speed is determined by the FPS setting of 15 or 30fps.

    At 160x120, that's 38400 bytes per frame, at 15fps that 576_000 bytes per second, or a clock period of 1736ns per byte. That is about 34 instructions per byte that you can execute. At 640x480, 15fps, it's 9_216_000 bytes per second, ~108ns per byte, which works out to around 8 instructions per byte that you can execute.

    So, if you stick to 15fps, you can certainly move enough data to achieve 640x480 resolution, the trick is storing that data in memory before you can stream it to another location. If you choose to down sample the image data, you could store 1 pixel per byte and store 1 frame at 160x120 in memory (19200 bytes). If you pack the data at 6 bits per pixel (like the Prop displays VGA), you could store 1 frame in 3600 longs.
  • pedwardpedward Posts: 1,642
    edited 2012-01-16 16:16
    Tubular wrote: »
    Yes, Phil made a Phil made a really neat NTSC frame grabber recently. This is probably the most flexible in the long term and should be really cost effective too as you could use cheap security camera modules. Cell phone cameras are notorious for being only available for a relatively short time.

    I've used the 4d systems uCAM-TTL successfully in a commercial job. You can read a 160x120 "preview" image which can be displayed by the prop using Kye's 160x120 driver. Then when you want to save the 640x480 image the camera does the JPG compression which saves on storage memory (but the prop would struggle to decode the JPG, hence the preview mode is useful. The 640x480 compressed images were ~20kB in size, which can fit inside the Prop memory, making transmitting a single image over bluetooth, xbee, gprs etc straightforward.

    Yeah, the next camera up does 1.3MP images and JPEG, I suggested the lower camera because it has a lower resolution and a larger image wouldn't be easily processed by the Prop. You could definitely use the bigger sensor and do JPEG to SD card and realtime sample at 160x120. Also, SparkFun says they have a long term supply of these modules, both models.
  • pedwardpedward Posts: 1,642
    edited 2012-01-16 17:45
    I did some looking at the datasheet on the 1.3MP camera, it has a min clock of 6Mhz and you can reduce the data rate to 1/4, or approx 7.5fps. The clocking of the data out is based on the EXTCLK that you feed to the module. At 1.3MP continuous, it needs a 17Mhz EXTCLK to keep up. I suspect that this module is much more flexible than the .3MP camera, also the pad layout is square instead of funky. There is also an app note on how to setup and use the 1.3MP camera. Both cameras are $9.95, but don't have a breakout board available. I think a simple breakout board with PTH vias would work for mounting this camera, just solder each via 1 at a time.

    1.3MP data sheet: http://www.sparkfun.com/datasheets/Sensors/Imaging/TCM8240MD_E150405_REV13.pdf
    AppNote: http://www.sparkfun.com/datasheets/Sensors/Imaging/TCM8240MD_APPNOTE041214.pdf
  • Duane DegnDuane Degn Posts: 10,588
    edited 2012-01-16 22:49
    pedward wrote: »
    I haven't used it, but I researched and read the datasheet on it back when I first saw it. It outputs RGB 5:6:5 via an 8 bit parallel port and you set all the config registers with I2C. Its seems to be fairly simple and doesn't have any funky encoding to deal with. I was thinking a 160x120 mode would be simple to work with.

    I thought I saw that Phil had done something recently with cameras? Or am I cornfused?

    I think it would be great to be able to use this or the other $10 camera from SparkFun with the Propeller. Based on some of the comments on the product page, interfacing with the camera appears to be non-trivial (possible errors in the datasheet).

    I'm also unsure about what type of level shifting hardware would be required when using one of these cameras with a Prop. I was hoping you (or some other forum member) has already used these cameras with the Prop.

    Do you think there's a way to connect the Prop to these cameras without a breakout board? (I'm guessing a board would need to be made.)

    I know Phil has several different camera projects. I've tried to follow what he's done. The NTSC capture Tubular mentioned was pretty low res.

    I personally would really like to be able to capture a color image with the Prop that has a higher resolution than Phil's NTSC capture method.
Sign In or Register to comment.