SparkFun Forums 

Where electronics enthusiasts find answers.

Have a good idea for a new product for SFE or Olimex? Let us know!
By KreAture
#61714
Agreed. 404 not found.
By Twingy
#61717
Domain renewal was today as luck might have it, give it a few more hours.
By jeanseb
#61948
Twingy wrote:Here is a technical report I compiled for those interested in using the TCM8230 and TCM8240 cameras.

http://www.js.cx/~justin/documents

So... What is the final cut with this?

Can the TCM8240 be used in 1.3M pixel mode? Can the JPEG feature be used? If not, what are the road blocks?

Thanks
By Twingy
#61958
What I described in this report was a general technique for capturing data from 8-bit I2C image sensors (cameras). You can apply this technique to capturing data off the TCM8240MD and other cameras as well. I don't see any issues with using this technique to capture data at 1.3MP provided your processor has enough internal or external memory to store the data.
By MattyZee
#62461
I've only just joined this thread as i'm about to place an order for one of these cameras and have been going over and over the datash33t trying to get my head around things. I may be way off here but i have a couple of thoughts.
buffercam wrote: Also, I noticed that if I set the PLL mode to 0x1 instead of 0xF, both error flags become set ("ENC_ERRN" in addition to "FULL_ERRN.")
I assume the FULL_ERRN is because your not capturing data quick enough and its filling up the internal FIFO but not sure why your getting the ENC_ERRN .... do you reckon your reading it fast enough?
buffercam wrote:Here are some other things that I've noticed:
In the DQT structure, I received a "length of field" of 0x84. This matches the length of the DQT data that I received, but does not match the length mentioned in the datasheet (pg. 21 says it should be 197bytes=0xC5).

The other structures match what the datasheet says as far as length of field goes (SOF, DHT, and SOS).
(As long as you realize that the datasheet has a typo in the SOF length of field - it should be 0x11 instead of 0xC5 - someone forgot to change it after copying and pasting.)
Looking at your pic, i can see the Y & U Quantisation tables but there is no V table (you can see the Y starting with 0x00, the U with 0x01 but there is no 0x02 for the V table) So it doesnt have the associated 64byte table. This adds up: 132(0x84) + 65(1+64=0x41) = 197(0xC5)
buffercam wrote: Any ideas as to why the image data repeats and why I'm getting the error code?
I have an idea, but i have very little experience with JPEG compression, so feel free to shoot it down...
Going back the YUV Quantisation tables (DQT data), the datasheet says on page 20
The host can adjust the picture quality mode (namely compression ratio) by sending a specific quantisation table or by sending Q table gain via IIC bus
Having a look at the registers, there is obviously no room for 3x 64byte tables so i can only assume we only have access to the gains? The closest i can see (guess) are registers 0xE9 & 0xEA called DYQTG & DUVQTG. As a total guess, could they be DefineY/UV Quantisation Table Gains ??

Can you verify the default values for these two registers? can you try adjusting these and see what happens? I wonder if one is acutally zero and causing the weird repeat data?

Just a few thoughts to maybe spark discussion here again (until i get my camera modules for me to try myself :-) )
By buffercam
#62777
Great job on the summary, Hugh.

Nice insight on the Quantization Table Gains, MattyZee. That's something that might help.

Here is all of our documentation on our project from last semester:
http://www.buffercam.com
(The latest stuff is in "Documents" and then the "Final Report" section.)

Here is the latest video (352x288 at 2.8 FPS):
http://www.prism.gatech.edu/~gth681s/TCM8240_video.wmv (~5MB)

I'd really like to get JPEG working. Our hardware setup should be able to handle it - we just need the correct register settings.

I'm quite busy this week, but I should be able to pick things up again next week. I'll try changing the gain values and see if that helps.

Regards,
David
By bhaskarapte
#62977
Hi,
I am trying to interface the camera with an FPGA. I am still in the problem for interfacing through the IIC bus, that what is slave address and subaddress? :( It may be the foolish question for those who have interfaced it, but I am the beginner . So please help me out to get the subadress.
By MattyZee
#63242
bhaskarapte wrote:Hi,
I am trying to interface the camera with an FPGA. I am still in the problem for interfacing through the IIC bus, that what is slave address and subaddress? :( It may be the foolish question for those who have interfaced it, but I am the beginner . So please help me out to get the subadress.
I haven't got my camera yet so i haven't actually tried this yet, but page six of the datasheet shows the Slave address as 0b0111101 (or 0x3D in hex). Then the sub addresses are the addresses of the registers listed on pages 7- 10.

Its been a while since i worked with FPGAs, but last time i did i used the I2C core from OpenCores. Have a look at the projects here http://www.opencores.org/browse.cgi/by_category

I think i used this one
http://www.opencores.org/projects.cgi/web/i2c/overview
So if you dont have your I2C controller coded up yet, that might give you a head start...

Hope that helps
By bcr
#63268
Anybody using this with a gumstix or other ARM9 board? ARM9 SoCs have a built-in camera interface that seems to be compatible... should be far less work than bitbanging it or building your own FPGA/CPLD glue logic
By bhaskarapte
#64060
Hi,
I am getting the dclk but of the same frequency as extclk. and also hblk and vblk are low always. d3 and d7 are high, else every pin is low. Plz anybody tell me hw to activate hblk and vblk
By buffercam
#64480
See this post.
That initialization was based on ma4826's original settings.

In short: 0x02 0x00 //Set Camera Active

As a side note, we toggled the reset during initialization, but I don't think it was necessary.
It might be something to try if it's giving you trouble.
Code: Select all
I2CWrite(0x02,0x00); //Set Camera Active
usDelay(2);
I2CWrite(0x02,0x40); //Set Camera Reset
usDelay(2);
I2CWrite(0x02,0x00); //Set Camera Active
By jwg
#64624
Have any of you been able to capture JPEG yet. I am interested in hiring a contractor for advice on how to get this module to capture a JPEG and provide programming examples.

Please let me know - Regards, Jim

P.S. I am a newbie so if this post is inappropriate for this board I apologize in advance, and please let me know.
By buffercam
#64626
jwg,

No one here has figured out how to get JPEG working.
The camera is not well documented, so it is difficult to debug.

MattyZee has suggested changing the quantization table gains (DYQTG & DUVQTG), but I have not yet found time to try his suggestion. I'll post and update when I do.

-David

EDIT: My adviser put it like this: "I'm sure this camera is used in a gazillion Toshiba cellphones - the problem is that the rest of the documentation for the camera likely consists of internal Toshiba documents written in Japanese."
So if you can find a Japanese-speaking contractor with ties to Toshiba - you'll be set!
By JCI-Lightyear
#64950
Hi to all people in this thread !!!

I have found this TCM8240 camera a lot time ago. I think its great. But for different reasons I have never bought it and started to play with it.
These last two weeks I have been reading its datas**t completely more that one time. And I also read carefully about the 80% of this thread.

I have also read about BufferCam job(I read almost all documents in his Web Page). Really amaizing project !
Now I think I am ready to buy it, but firstly I need someone's advice.
I am from Argentina, and I will spend at least USD30 in ship*ing)

Do you think that it will be possible to read JPEG data from the camera?
I think that RGB data will be also great, but what made me love this camera was JPEG compression.

I work with PIC MCUs. I think that my problem is the minimum 6MHz frequency at Extclk.
But as there is no MCU with 300KB of RAM.....I think that with any processor it will be necessary to add external components just as RAM for buffering

I plan to use 512Kx8 RAM....and address and control it with pure logic (counters and other gates). The PIC will only send commands and check when data of a picture is complete. The buffering will be automatic.

I also thought on buying C328R camera module, but it is 5 times more expensive than TCM, and doesn't have 1.3 Mpx

Conclusion: for simple RGB output I will need external logic and memory.
It is not worth for VGA resolution.
But it will be worth if I can take JPEG 1.3 Mpx data from it.

Let's say what you think....


PD: I had to copy/paste sentence by sentence because I used "forbidden word". My language is not English (Spanish), but what is wrong with "ship*ing" ?
  • 1
  • 14
  • 15
  • 16
  • 17
  • 18
  • 31