SparkFun Forums

[lilalinux]

Unfortunately I got no usable replies. Other people simply use it with 2.5V, but I wouldn't do that. I use it with 2.8V and a level shifter.

[KreAture]

The 2.5 vs 2.8v calibration has to do with the internal photodiode array and brighness/color levels. It is normal for sensors to need calibration if they can run on multiple voltages.
Why 2.8 and 2.5 are specifically mentioned may be some OEM thing as these cameras were developed for a specific customer by Toshiba. The only thing that will be wrong if you run it on wrong voltage is the colors/brigness/tones. It should be possible to test and find out what looks best.

As for me, my main issue is my controller is 3.3v with 2.8v minimum for "1" detection (0.3v or less for "0" I think.) Thus I have serious issues talking to it. Will try running it at 3v as that is max.
Then maby I can calibrate it for 3.0v too

[KreAture]

Come to think of it, there may a 3'rd option. Using 3v or so on the IOVDD while using 2.5 or 2.8v on the DVDD for the photodiode array.

It would also reduce the noise in the image, as the IO is causing the noise. This might be why the chip has split VDD like that. Needs an extra regulator though.

[jarevalo]

Hi everyone,

I have been following this thread some months ago and I got 2 modules ready for testing.

I want to know if is there any trouble about using 2.5V power. The "helpfull" datash**t says in pag. 25 "Note: If using 2.5V operation, must input setting command. (Default setting is 2.8V operation.)", and I'm concern of this because my design uses 2.5V power.

Can anyone help me about this? Thank you in advance.

[KreAture]

Well, I just ran my sensor on 3v today as 2.8v was too close to my avr32's 3.3v * 0.8 limit for noise immunity. Result is great, now images transfer nicely with almost no glitching. (Still not perfect.)
Images do appear a little more washed out.

As soon as I get the ffmpeg compressor working right I'll post a vid

[kelvin.vincent]

Hello ChrisJP or KreAture,
I am also working on an Image project that will use TCM8240MD, so
if you have an extra PCB that can send me, I will be very happy to avoid making the PCB by myself.... Would you please let me know how to pay you? Thanks in advance.

[chrisjp]

Hey,

I'm happy to send you a PCB if you like. The only limitations for you will be that it needs 2.8/2.5V for IO. It has the interface for a reg to provide the core voltage.

If you're interested drop me a PM.

[mkmckenzie]

Just wanted to mention: I'm building a TCM8230MD with read-out done by an XMEGA (atxmega128a1... the XPLAIN demo board to be exact (8MB SDRAM!)).

Did anyone end up selecting and using a nice level shifter for use on EXTCLK (and/or SDA/SCL) that they would recommend? I'm getting ready to use the MAX3378 but I'm getting nervous about its so-so timing specs...

So, I think I'll just use the resistor trick for EXTCLK, the Hi-Z/Output-Low trick for RESET, and use the 2 channel bi-directional shifter (MAX3373) for I2C... just to get a little of everything in there.

[KreAture]

Just wanted to mention: I'm building a TCM8230MD with read-out done by an XMEGA (atxmega128a1... the XPLAIN demo board to be exact (8MB SDRAM!)).

Did anyone end up selecting and using a nice level shifter for use on EXTCLK (and/or SDA/SCL) that they would recommend? I'm getting ready to use the MAX3378 but I'm getting nervous about its so-so timing specs...

So, I think I'll just use the resistor trick for EXTCLK, the Hi-Z/Output-Low trick for RESET, and use the 2 channel bi-directional shifter (MAX3373) for I2C... just to get a little of everything in there.

I don't think you have to do it this complex.
I haven't tested it yet, but the cam has two VDD's, one for logic and one for sensor array. Maby it supports 3.3v on logic with 2.8v on sensor?

I am now running mine on 3.1v which is close enough to allow 3.3v directly in. Will see if I can find the right calibration.

[KreAture]

Well... So far I haven't found any register that seems to help on calibration.
I have however made my driver much better.

I wrote a new system for handling bit-mapped options so now I can add a line in a table and it will automatically handle the register.
It also adds a debugfs file for it and does read/write so one can cat any named option to check it's value instead of dealing with entire register bytes.
Works great and should be good for debugging the tcm8240 also.

I'm itching to release this and I really hope I can soon.

Maby I can get a go-ahead to release a binary image for the NGW100 in the meantime?
Something that can be put into the onboard flash and allow the board to support both 8230 and 8240... (After all, both my drivers can co-exist as loadable modules or built into core and they simply abort loading if cam is not found.)

[uLuxx]

Hi,
i am currently building up a design with the TCM8230, and, like the bigger brother, it can output YUV-Data.
Has anyone yet used this mode? How is the data encoded?
Regarding Wikipedia information, U and V are signed fractional numbers, and I don't think that they ouput it like that in these 8bit values.

Thanks in advance!

uLuxx

[lilalinux]

I didn't yet try YUV, but it's all explained in the datasheet (TCM8230MD.pdf) on page 12:

Code: Select all

8bit parallel image data 
      1st   2nd   3rd   4th     1st 2nd 
DOUT0 U0(n) Y0(n) V0(n) Y0(n+1) B0  G3 
DOUT1 U1(n) Y1(n) V1(n) Y1(n+1) B1  G4 
DOUT2 U2(n) Y2(n) V2(n) Y2(n+1) B2  G5 
DOUT3 U3(n) Y3(n) V3(n) Y3(n+1) B3  R0 
DOUT4 U4(n) Y4(n) V4(n) Y4(n+1) B4  R1 
DOUT5 U5(n) Y5(n) V5(n) Y5(n+1) G0  R2 
DOUT6 U6(n) Y6(n) V6(n) Y6(n+1) G1  R3 
DOUT7 U7(n) Y7(n) V7(n) Y7(n+1) G2  R4 
      YUV mode                  RGB mode 

[uLuxx]

I didn't yet try YUV, but it's all explained in the datasheet (TCM8230MD.pdf) on page 12:

Code: Select all

8bit parallel image data 
      1st   2nd   3rd   4th     1st 2nd 
DOUT0 U0(n) Y0(n) V0(n) Y0(n+1) B0  G3 
DOUT1 U1(n) Y1(n) V1(n) Y1(n+1) B1  G4 
DOUT2 U2(n) Y2(n) V2(n) Y2(n+1) B2  G5 
DOUT3 U3(n) Y3(n) V3(n) Y3(n+1) B3  R0 
DOUT4 U4(n) Y4(n) V4(n) Y4(n+1) B4  R1 
DOUT5 U5(n) Y5(n) V5(n) Y5(n+1) G0  R2 
DOUT6 U6(n) Y6(n) V6(n) Y6(n+1) G1  R3 
DOUT7 U7(n) Y7(n) V7(n) Y7(n+1) G2  R4 
      YUV mode                  RGB mode 

yes i know, but if you have a look at the wikipagehttp://de.wikipedia.org/wiki/YUV-Farbmo ... arbmodells (don't think about the language, just watch the formulas) you'll see that as results for U and V, you can get values in the range of -XX.X to +XX.X and I wonder how they encoded these numbers in the YUV ouput.

uLuxx

[uLuxx]

I need to know where the important data is stored in the UV-Part, are these dynamic values, which i can divide by 2 or 4 and still have good resolution, or is the information stored in the 3 LSBs and the rest is static.

[KreAture]

The cam raw color depth is 10 bits. It sais so on the first page of the datasheet.
The data is integer data and the datasheet is very clear on the encoding. YUV is 4:2:2 and RGB is 5:6:5 encoding.

I agree that the 5:6:5 coding is a bit more understandable as the data comes in two byte groups (a 16 bit words) where the first 5 bits are blue, next 6 are green and the last 5 are red.
One group is a single pixel.

For YUV mode it get's confusing as it's really UYVn Yn+1 that is being transmitted.
That is, Every second pixel only has Y data, 8 bits. There is no U or V, you have to interpolate.
Data comes in groups of 4 bytes and contain two pixels. First 3 are the first pixel UYV. Next byte is the next pixel Y only.
Correct me if I am wrong here guys, but the datasheet seems very clear...

For display purposes it's horrible, but for transmission and coding it's a good format that cuts the bandwidth of a signal in a way you won't notice much.