TCM8240MD connector and example

Archive New Product Ideas
241

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.

242

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 !!!

243

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!

244

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…

245

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 :wink:

246

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.

    247

    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!

    248

    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 :o

    I asked before, I ask again: Does anybody know the minimum distance between the camera and an object, in order to have clear focus?

    249

    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.

    250

    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. :smiley:

    251

    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.

    252

    Aerospace:
    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.

    253

    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!

    254

    http://i831.photobucket.com/albums/zz23 … 0006-1.jpg

    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.

    255

    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

    256

    @lastid: I’ve also just started playing with this camera (actually, the simpler TCM8230 variant) for a project where I need to sample an image at very close range (~ 1cm). Regarding the focus, I have some good news and bad news.

    The bad news: The lens is on a threaded barrel for focal length adjustment, but the chips come from the factory pre-focused (probably for “infinity”, though I haven’t measured…think typical fixed-focus cellphone cam), and fixed in place with some kind of thread-locking adhesive.

    The good news: I’ve worked out a pretty reliable procedure to unlock the threads and allow for adjustment. You can then adjust the focal distance for closer range (up to <1cm) by screwing the lens out (counterclockwise). Here’s how to do it.

    1. Find the seam where the main rectangular body (the part the lens screws into) mates with the base (the halves are held together by glue), and dab some epoxy (or other heat-safe glue) over the seam. The reason will become evident in the next steps.

    2. Bake at the highest allowed storage temperature from the datasheet (60C?) for at least one hour.

    3. Remove from oven and put a couple drops of isopropanol (or 91% rubbing alcohol) where the lens screws in, allowing it to flow into the threads. Let it sit for several minutes (if too much evaporates, add more). Although it does not dissolve the thread glue, the combination of heat and solvent seems to loosen its grip on the plastic considerably. Unfortunately it seems to have the same effect on the glue that holds the rest of the package together, hence the glue reinforcement earlier.

    4. There is a pair of small indentations (notches/holes), one on either side of the square lens face. Clamp the part gently in a vise, and with some very needle-nosed pliers/tweezers inserted into these notches, very carefully rotate the lens counterclockwise. There may be a discernable ‘snap’ as the thread glue releases. Once this happens, you can unscrew the lens completely and (if desired) run an isopropanol-soaked Q-tip over the threads to dislodge any remaining glue.

    I tried making a cast of the lens face and using that to rotate it, but there’s very little face for it to grab onto - the tweezers worked better for me.

    Some pictures of the results:

    http://tim.cexx.org/projects/tcm8230/tn_first_test.jpg

    http://tim.cexx.org/projects/tcm8230/tn … st_640.png <— resulting image

    http://tim.cexx.org/projects/tcm8230/tn_dissect.jpg <—this is what can happen without reinforcing the main package glue :stuck_out_tongue:

    257

    Well, even though I said I was going to make headway on this about a month ago, as things go, I have only just finally begun to actually get some data out of it.

    This camera is only useful to me if I can get the JPEG compression to work, so that is my end goal.

    I still have a couple of kinks to work out of my firmware (timing issues w/ data transfer, etc) but I have been able to play with the register settings and I have found some things out…

    1. PLL mode (0 is off, 1-F is on). It does make a difference what value you use (1-F). Higher values → faster data clock. I believe JPEG needs at least 17 MHz data clock???

    2. Both error flags (0xFA) are set as soon as I turn the JPEG compression on. With JPEG off only FULL_ERRN is set.

    3. This is going to take awhile :slight_smile:

    I am reprogramming my PIC tomorrow, hopefully the update will fix the missing bytes I’m finding in my data.

    258

    I just received a few of these cameras, and just like others, they are useless to me unless I can use the JPEG output. It is somewhat disheartening to see so many issues with it, but I have not found any other COTS single chip solutions (other than the C328R, which has a boatload of other issues) so I hope for this to be the answer.

    Hopefully some of the people in the past month who have been speaking of working with the JPEG output will respond back, and I will do the same, so we can attempt to collaborate.

    FYI, I am using a PIC18F8722 at 25 MHz.

    259

    I have just recently been pointed to the Micron (aptina) MT9D131, which is a SOC sensor with JPEG compression. However I am already pretty far along with the TCM8240, so I am going to try a little longer to see if I can get it working.

    Currently I am trying to adjust the settings to make the error flags go away (I think one of them indicates an internal FIFO overflow, which means my compression is too low…)

    I am getting data out, and while I can recognize some structures, things are missing and there is weird data that comes out before the SOI flag.

    "000000000 8E 84 80 80 87 84 80 B6-90 81 80 80 B0 97 84 80

    "000000010 A9 9C 81 80 80 A8 A5 81-80 A1 AA 82 80 80 80 A0

    "000000020 A0 A0 A0 80 80 80 FF DB-00 84 00 10 0C 0E 0C 0A

    Here is the first 3 lines of data that come out. Notice here the SOI flag is entirely missing, but sometimes the ‘FF’ portion comes through. And then it starts with the DQT structure, but the field length is wrong. I am going to try a different chip since the one I’m using now saw some abuse during initial fab.

    260

    Anyone can give me a clue about this?

    I set up the camera with the right voltages on IOVDD, PVDD, DVDD. Everything seems to be fine. The Dclk outputs the same frequency as the Extclk(I used the ccp module in pwm mode from a pic18f4620)

    The problem is that a cannot get any acknowledge bit. I saw on oscilloscope SDA and SCL(pullups=10k) signals and they seem to be fine. I tried to slow them down a little bit thinking that they might be to fast , but in datash**t the maximum speed for i2c is 400 khz.

    I accidently connect a few days ago SDA and SCL to some pins of the uC that where allready pulled up to 5v. Might this be the reason ? I’m confused because the Dclk outputs the same frequency as the Extclk input.

    The i2c bus on the camera needs necessarly Extclck to work?(I’m thinikng that the frequency of the pwm is not proper, its about 5Mhz and not 6 the minimum)

    Regards