TCM8240MD connector and example

Archive New Product Ideas
261

Aerospace:

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

Can you be a bit more specific? I mean, which DCLK frequencies do you get with the 1-F PLL settings and what was your input EXTCLK frequency?

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

Please post register settings. Especially register 4.

Also, has anybody discovered a way of getting just 8 bits per pixel? Raw 8-bit bayer RGB in particular would be great.

I’m asking because I’ll be trying to transfer data from this camera over a serial bus (SPI) at perhaps as little as 25 Mbit/s, so I need all the help I can get to reduce the output rate. Plan B is to convert RGB656 to RGB332 on the fly during parallel to serial conversion.

Page 25 of the datashit[1] says you must change a setting to operate the camera at 2.5 V instead of 2.8 V. Did anybody find it?

[1] Deliberate misspelling to avoid forbidden word filter.

EDIT: Fixed the quoting.

262

First PLL:

Input clock = 10 MHz

PLL setting → DCLK Freq (MHz)

1 → 11.2

2 → 12.5

3 → 13.7

4 → 15

5 → 16.3

6 → 17.6

7 → 18.8

8 → 21.1

9 → 22.3

A → 24.7

B → 27.3

C → 30

D → 31.3

E → 33

F → 35

Also, while JPEG was on, if I set the PLL to 0, DCLK turned off completely

263

Second Register settings:

Currently this is my initialization:

Address : Value

02 : 00

03 : 17 //DCLK = 18.8 MHz, Polarity inverted

04 : 50 //JPEG on, DOUT on, YUV sel, PICSIZE = full, Picmode = 1280x1024

05 : 00 //quarter speed (in JPEG, this doesn’t affect DCLK, just the time it takes to output a full frame… possibly means different compression ratios)

1A : FF //H_Count → 1023

1B : B3 //H_Count and V_Count adjust

1E : 6C //SP_Count (probably wrong)

1F : 09 //rest of SP_Count

58 : 20 //Exposure time (from other comments in this forum)

0B : 00 //White Line Off (from other comments as well)

0E : B0 //Change for different PIC size (probably wrong)

11 : 6A //same as ‘OE’

14 : 33 //same as ‘11’ and ‘OE’

E6 : 08 //Read JPEG in 4 byte units (cant tell if this does anything)

Hope this helps move things along

264

Hello…can i have a wiring connection between MCU and TCM8240MD camera??? cos i have little confuse about the EXTCLK pin should connect to where pins of MCU???

265

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

razvantgf:
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)

IIRC, it’s been mentioned already that the camera just won’t initialise at less than 6 MHz.

266

lastid:
I want to read barcodes with this camera. The minimum distance I want to achieve is in the range of 2cm-10cm.

I tried the oldest trick in the book on a USB webcam: Using a needle I made a tiny hole in a piece of paperboard and placed in front of the camera lens, flush to the camera. Then it reads barcodes fine at distances of 6 cm - 14 cm. It does however reduce the amount of light reaching the camera and the size of the image. You will likely want to experiment with different hole diameters and distances between hole and camera.

267

Aerospace:
02 : 00

03 : 17 //DCLK = 18.8 MHz, Polarity inverted

04 : 50 //JPEG on, DOUT on, YUV sel, PICSIZE = full, Picmode = 1280x1024

05 : 00 //quarter speed (in JPEG, this doesn’t affect DCLK, just the time it takes to output a full frame… possibly means different compression ratios)

1A : FF //H_Count → 1023

1B : B3 //H_Count and V_Count adjust

1E : 6C //SP_Count (probably wrong)

1F : 09 //rest of SP_Count

58 : 20 //Exposure time (from other comments in this forum)

0B : 00 //White Line Off (from other comments as well)

0E : B0 //Change for different PIC size (probably wrong)

11 : 6A //same as ‘OE’

14 : 33 //same as ‘11’ and ‘OE’

E6 : 08 //Read JPEG in 4 byte units (cant tell if this does anything)

I too think you should first try without JPEG compression to see if you get a valid YUV image at all, especially with the modifications to HCOUNT, VCOUNT, SPCOUNT and such.

A possible aid in debugging the JPEG structure would be registers 0xF0:0xF1 Define Restart Interval to output a 0xFFDD DRI marker and periodic 0xFFD0…7 RST markers.

It looks like there are several registers related to JPEG in the 0xE9 to 0xFA area:

  • - 0xE9 Define (download?) Y quantisation table gain(s)?
  • - 0xEA Define (download?) U/V quantisation table gain(s)?
  • - 0xEE V/U/Y quantisation table select?
  • - 0xEF V/U/Y Huffmann table select AC/DC coefficient?
  • - 0xF6:0xF7:0xF8 ENCDCNT = Encoder Discrete Cosine Transform?
    • 268

    ma4826:
    0x0B 0x00 White Line OFF

    According to the datasheet, the default for register 0x0B was supposed to be 0x00. How nice. :-(
    269

    Hi,

    Regarding the JPEG mode.

    if we know, in which mobile phone the camera modul was build in, we can analyze the I2C protocoll.

    Maybe somebody know ??

    Have a nice day

    With best regards

    Siegmar

    270

    Hi all,

    I’d like to make my comment on the Application Note for TCM8230MD by Justin L. Shumaker AKA Twingy

    (http://www.arl.army.mil/arlreports/2009/ARL-TN-344.pdf) which I found extremely usefull.

    He wrote on p.7:

    The camera has a hexadecimal address of 0x60

    In fact, 60 is the decimal value of its address which is 0x3C. See p.8 of TCM8230MD's datasheet.

    There is only one command that must be sent to the camera for it to begin sending images—0x02.

    In fact, it is IMHO all about the the second documented register whose address is 0x03. Setting DOUTSW bit to zero starts the cam.

    BTW, you won’t need a level shifter if you run your micro at 3VDC. It seems as if TCM8230MD inputs are 3V-tolerant.

    271

    Dmitry’s right… so far, I have run the TCM8230MD with DVDD=1.5V (low-dropout linear regulator) and with PVDD and I/O voltage up to 3.3V (for PIC18F2450/4450 microcontroller) without any trouble, and no sudden ramp-up in current that would indicate protection diodes becoming active. (Fair warning - PIC18xxxx do not have much memory, so you may be limited to buffering and sending 1 line at a time at 320x240 or 640x480 at full color, depending which. But the TCM8230 at least handles the voltage well.)

    For anybody interested, I have posted a free EAGLE footprint for the '8230: http://tim.cexx.org/projects/tcm8230/tcm8230.lbr

    272

    Undocumented registers is the worst thing I know of… Next to stuff that doesn’t work at all ofcource.

    I have been writing a driver for the TCM8240 for Linux. (Running Linux on NGW100 card with AVR32.) I can thusly handle the data fairly easy now and am running the camera at 20 MHz input clock with PLL off.

    I have tried using the initial values of the regs as well as the calculations in various sources but am having a hard time accepting the quality of the results. I get a lot of lines and such in the images, as well as horrible color reproduction.

    I am grabbing data at 1280x960 for the moment. (4VGA)

    Setting the cam to CBMODE 4 gives me lovely colorbars and comfirms that my transfer algorithm and driver structure is sane.

    Has there been any more progress on the registers? Can we recap what we have learnt so far?

    273

    The datasheet and the appnote does not agree on many values.

    For instance, SP_COUNT defaults to 1024 in the docs which also sais PICSIZ defaults to 0. It also states that H_COUNT defaults to 691.

    When I check form power-on, All this is correct.

    Appnote sais H_COUNT defaults to 713 and that internally 677 is added to make the count 1390.

    It then states the formula SP_COUNT = (H_COUNT + 183) * 2 for PICSIZ=0. This would give an SP_COUNT of 1792 for H_COUNT=713 and of 1748 for H_COUNT=691.

    This doesn’t make sence. Why should some stuff be correctly initialized and other stuff not?

    I’ve also fiddled with some of the other registers and many seem to have the same effect of sliding the image left/right or corrupting it with vertical lines. If the H or V_count is too far off it looks like one is missing the image alltogether.

    This really doesn’t add up at all.

    Any insight would be apprechiated.

    I could post some examples but without all the settings, they are meaningless.

    274

    Example of 1280x960 can be seen here:

    http://kreature.org/ee/avr/cmos_cam/h_count_1010.png

    275

    Enother example using colorbar mode 4 (much prettier):

    http://kreature.org/ee/avr/cmos_cam/128 … mode_4.png

    This just confirms that my data transfer is correct. I use the cams YUYV-style transfer.

    Finally, for my eternal glory a pic with a subject:

    http://kreature.org/ee/avr/cmos_cam/1280x960_awful.png

    So, it is possible, if only I could find the right register-values.

    276

    I did this test a year ago. Hope you helps.

    Address        Value
-------	     -----
0x0D           0x01      //Optional?
0x0B           0x00      //White Line OFF
0x6D           0xA1      //ABW_SW -> ON
0x58           0x10      //Exposure time
0x05           0x80      //Frame Rate full
0x1A           0xFF	
0x1B           0xB3
0x0E           0x14
0x11           0x6A
0x14           0x33
0x1F           0x0B
0x1E           0xE7
0x04           0x18      //RGB Full Size 1280x1024, OUT ON

    In my SRAM only fit 200 of the 1024 lines.

    http://webs.ono.com/ma4826/pbbmp_0x1F=0 … LL_OFF.png

    Best regards,

    ma4826

    277

    Thankyou.

    I will see if I can reproduce that today.

    Are you still using registers or have you started using the bitmapped fields I set up? I find the fields are great as they keep track of the different bits for you. Just be sure about the endian.

    I had to rewrite the fields for the avr32 as the silly thing is big endian…

    I guess the only safe way to use the structs is to use a define or something for the endianness. (I have it defined both for little and big now.)

    ONe wierd platform I tried had bit fields internally as little endian, but addressing in memory was big endian… That was a nightmare.

    278

    Finally got around to testing it ma4826!

    It works sortof. I am still getting banding though.

    After doubling the caps on my board it looked different.

    Adding even more made it different again.

    I say different, not necessarily better, but less blue though.

    I think my regulators are not fast enough to handle the frequencys I run at. Maby there is also an issue with their rating. The TCM8240 can draw up to 150mA on the 1.6v rail.

    I am running at 20 MHz so maby that amplifies the problem.

    http://kreature.org/ee/avr/cmos_cam/128 … ings_8.png

    That said. Is is atleas possible to recognise furniture…

    279

    halane34

    Your issue will be the datarate, but it is possible.

    You will have to use a clock frequency to the sensor that is high enough for it to function even if it is lower than the specified 6 MHz minimum.

    Further, you can reduce the output rate by setting the H and V count high I think.

    If you want to save yourself a lot of issues with image quality, I do suggest you use TCM8230 instead of TCM8240 as it has a complete manual and is fully automatic. Very little has to be done to it’s registers in order to make it output good pictures. TCM8240 is a nightmare untill we manage to understand and document it fully.

    280

    ma4826

    What clock did you give the cam as input?

    (Do you think it has any effect on the results?)

    My linux platform runns great and my driver for ISI-hardware and capture works well, but I can’t get those nice shiney pics you guys have…

    I’ve tried running it at 10 and 20 MHz but the images look identically awful.

    Edit:

    Sorry, just reread your post and you did say 12.5 MHz…

    Hmm. Must be something else then.