SparkFun Forums

[buffercam]

Lightyear,

I'm glad you found the report useful.
I do think it's possible to get JPEG working, but it hasn't yet been done.

Have you considered using the better documented STmicroelectronics VS6724?
It's harder to find, but it has much better documentation and it provides 2MP JPEG. However, it's been rumored that the VS6724 is being phased out (in favor of selling the camera in large quantities to large manufacturers).
See this thread for more info (including where to find):
viewtopic.php?t=10612
And you can google for the datasheet and more info.

I would definitely recommend using the AL440B FIFO instead of stand-alone RAM in order to make the memory management a lot easier. I investigated using stand-alone ram, but it's difficult to find counters that are wide enough and fast enough. And furthermore, the pin-outs on the counters seem to be unhelpful - they scramble the order of the output bits, which makes it more difficult to connect to the RAM. So a dedicated FIFO is definitely helpful. (Or you could use a FPGA in conjunction with stand-alone RAM.)

Someone asked me (in a PM) about whether the AL422B (3Mbits) could be used instead of the AL440B (4Mbits). I would say yes, but one downside of the AL422B is that it isn't quite big enough to buffer two CIF frames, while the AL440B is. But if someone gets JPEG working, that won't be an issue.

Good luck,
David

Edit: To be clear, I haven't used the VS6724. I am just envious of the better documentation.

[JCI-Lightyear]

Thanks for the help.
I have reading the forum about the VS6724. I have been reading datash*t, and the camera seems to be very well documented, but now it has been discontinued, and it is difficult to find it.


But I found a very good solution. With pros and contras.
The solution is VS6650 + STV0976. The first is 1.0Mpx camera and the second one is the image processor with built-in JPEG compression.
Pros:
-They have been created to work together. (Each datash*t reffers to the other).
-They are at Digikey for 1 quantity, in stock (USD21.88 the camera and USD 6.33 the processor)

Contras:
-I have only found "product brief" datash*t, it is a 3 page one(both have the same large)

But what is positive, that maybe ST people could provide a better datash*t if we ask them for it.
This camera and processor are SMIA compliant, and maybe as this a special protocol,etc....we should have to find info there (datash*t points to www.smia-forum.org)

About the TCM cam, have you tried every register at the "application note" paper?
Maybe there is the solution(as they seem to be the "very important registers to have it working")

- JCI-Lightyear

PD: If you read it carefully the application note, there it talks about an "output cock".....maybe engeneers from Toshiba wanted to say: "This is what you will have out from this camera, after spending your hole life in it".
I think we should ask them what have we got to do with this "special output". Maybe they have an idea....(or have tried it)... lol !!!

[Jalpa]

Hey guy's I just received a few of the TCM8230MD modules (low res version) and i'm starting to design my schematic.

I'm looking to use the cams for a machine vision project that will only require a few lines from each frame and perhaps skipping pixels if required to keep up with a 8 bit avr. If that works I plan to then try connecting two cameras to the one AVR and looking at them alternatively. The system only needs to inspect a few frames a second.

So this has raised a few questions, is there anyway to set the cam's I2C device address? So that more than one camera can be on the one I2C bus at once? Chips I have used in the past have left one pin or two that can be either pull up or pulled down to change the least significant bits of the address. looks like that's not the case here but thought I would ask incase I’m missed it in the datesh##t?
Looks like you can share the data bus as there is a register to set the data pins to hi-Z.

Any body got a Kicad, tested foot print for the low res (TCM8230MD) version?

Lastly thank y’all for this great thread, have spent a few hours reading though it all, doting down notes. Hopefully I will have something useful to contribute in return.

Wish me luck!

[lastid]

What is the minimum distance of placing an object in order to get a focused image? Has anyone tried this? I can't find anything in the specs...
Here's another thought for interfacing the TCM8240 (I'm not sure if this is already mentioned) : Video streaming through Ethernet. Using a Wiznet module for example in 100MBPS could do the job - and we do not have to worry about the video ram...

[Reaper]

did some one configured tcm8240 to function?
i think previous post are of 8230 and 8240 i think has diferents registers and aplication note sucks it sais active output in 1 and outputs are disable in 1 :S

if some one could help

thx in advance

[RogerL]

I have interfaced several chips like this at work (other vendors, never seen a perfect manual yet...)

Some things that I noticed when reading the manual regarding JPEG.

• only full frame (subframes are created in another flow)

  image page 3

  PLL operation required

  (JPEG is not available in case of w/o PLL operation)

  SOI/EOI marking of begin and end of frame

  image page 19

  HBLK is used as output data Enable

  image page 19

  Might stop with error condition, reset and go

  When data overflow in FIFO happens due to locally increased JPEG data ( locally very low compression) , data transmission is stopped after FE code addition and an error flag is written in the register table. After the host accesses the error flag register, the error flag is automatically reset.

But there is one thing that really is not mentioned. I think it has to run in YUV mode to work (as JPEG compression wants YUV data input).

The manual is not clear on how to get YUV working. But I have noticed some things
0x04 bit 3 = 0 (SELRGB)
0x8A and 0x8B registers default 0 (this might be the Y component)
0x8D register default 0 (YUV_MAX == YUV_MIN...)

First I would make sure that I can get valid YUV pictures of full frame. After that it would be time to add JPEG to the mix.

[Aerospace]

It looks like this thread has been inactive for awhile, but I was wondering if anyone here has had success with the JPEG compression. It looks like a trial and error process was used to get the RGB mode to work, and I would like to avoid that .

I only want to use this camera because of the JPEG feature, so if anyone has figured out which registers need to be set to what to make this happen, I would greatly appreciate it.

Thanks!

[lastid]

I ordered a TCM8240. As soon as it gets in my hands, I will start experimenting.
I'm interested too about the JPEG compression, perhaps I can contribute here... and I may also need help too
I asked before, I ask again: Does anybody know the minimum distance between the camera and an object, in order to have clear focus?

[Aerospace]

How close do you need to get? I don't think it should be a problem.

You should check out the links buffercam posted to their project page, they have clips of some videos they recorded. It might give you a better idea of what to expect.

I am in the process of designing a PCB for this camera, and I will be sure to post my results (and questions) as I start poking around.

[mako1138]

I've also got one of these cameras on my desk, waiting for a breakout board and some free time. I'm planning to use an FPGA board with some SDRAM.

Let's figure this thing out.

[Aerospace]

Just finished my PCB. Im putting the Camera on a board with an AL440 FIFO chip and a PIC18f microprocessor. Im going for a standalone unit that will talk to the host via RX/TX lines on the PIC.

I am going to have somebody else look over my board before I send it out to get made, but I will post as soon as I start putting things together.

[lastid]

How close do you need to get? I don't think it should be a problem.

I want to read barcodes with this camera. The minimum distance I want to achieve is in the range of 2cm-10cm.
@Aerospace: If your serial link speed is 120kbps, you will need about 5 minutes to send a full 1300x1000x24 bits frame without compression. That's an inconvenient time, even for experimenting. JPEG is a must.
Of course using a QCIF resolution (176x144x24) for experimenting, will result in a decent time of 6 seconds.

[Aerospace]

This camera is really only useful to me if I can use the JPEG, so the size of an uncompressed image is not a concern, although I may have to experiment with a smaller image before I get the JPEG working.

Also, this camera should work fine in the 2 - 10 cm range. It is hard to know for sure before plugging it in and testing it, but worst case scenario you could always do some sort of lensing to move the focal point.

But I digress from my main reason of posting. I sent my board out for fab today, and I expect it back early next week. I could possibly get some early results by the fourth!

[Aerospace]

Finally got my circuit boards in. Should be populated by tomorrow, although I probably wont have time to play with them before the long weekend.

[ghavenga]

Totally cool - at last someone is getting some time to work with this thing - good luck!

I've got to get busy and get a daughterboard made for the ATNGW100 I'm using. The CPU has a port on it dedicated to hoovering up image data.

Greg