Micron/Aptina MT9D131 JPEG Camera

Hi all,

I have simply been trying to take a picture with this part for a school project. I have been communicating with the sensor via the two-wire interface successfully for the past few days, but that ceased this morning. I have tested every bit of my hardware in every way I can imagine, and I always come to the conclusion that the MT9D131 is simply holding the Sdata line low. I can’t think of any reason for why this should be happening, and I was just wondering if anyone has run into a similar problem?

Any help is appreciated, thanks!

Alan

Hi Alan,

Try checking the peak-to-peak value of your clock input. I had this same problem (data line being held low) and it turned out the clock input wasn’t reaching 3 V. If not this, perhaps its stuck in a standby mode? It has both a hardware and a software (controlled by setting certain registers) standby.

Hi guys,

As I am interested in JPEG camera as well, can anybody email me the MTD131 Developers Guide?

I have filled the form for document request on Aptina website, but I had no response from them.

Thank you in advance.


No more need; I found it.

Hi everybody.

I am considering to buy 4-5 sensors for my undetectable wireless camera project. Can somebody please send me Developer’s Guide for MT9D131, because i’m not sure that i’ll be able to make it work. My e-mail: nickkim@yandex.ru

Hello All,

I am using MT9T111 and MT9T112 Camera for my project. It is a 3.1MP Image Sensor SoC with JPEG output. I am facing some problem related to FIFO overflow and underflow. Can anyone help me with providing Developer’s guide for this sensor?

Regards,

Mohammadi

Hello,

In the begining of this thread someone said that in order to make a complite JPEG file I need to create and add JPEG header. So, can anyone say how does this header look like. I couldn’t find it myself that it why I need your help.

Also, I read about a developers guide, but registration at Aptina got me nowhere. Can someone sent me this guide to e-mail plz.

evgeny_strife@mail.ru

Hello,

can someone get me the “MT9D131 Developer Guide”?

dadebng@libero.it

Thanks

Hi Folks

This thread seems to have gone a bit quiet. Has anyone succeeded in getting this sensor to work reliably with jpeg ? I have yet to start work with the sensor but would love to hear if someone’s made any progress. Anyone game to post a sample photo ? It still seems to be one of the best documented sensors available at relatively low cost. I’m planning to interface to a Rabbit controller, probably using the Averlogic 440b FIFO.

Regards

Ian

Hello,

I would like to try and interface this sensor to a PIC or AVR and write JPEGs and if possible video at full res to an SDHC card. I’d rather not use a FIFO/SRAM, or a uProc with external RAM/Flash… so if I have a uProc with DMA and say ~65MHz, do you think this will be fast enough? I am not sure what kind of bandwidth is required for transferring the JPEGs…

Thanks

EdCa22, 65 MHz should be fast enough. I believe I’ve talked a little bit about the bandwidth requirements elsewhere on this thread.

iand2010au, I have gotten this sensor working reliably, here is an image:

http://i.imgur.com/A7aaF.jpg

The artifact on the top left of the image is the result of a software algorithm I set up to grab a low res thumbnail along with each of my high res photos. I understand it and it is not a fault of the sensor chip or the hardware design. A lot of the development work and troubleshooting is documented on this board, and the datasheet and development guide available from micron are great resources for working with this chip. I’d recommend familiarizing yourself with all 3 before you start. Best of luck!

Hello… can someone email me the MT9D131 Developer guide ? i think this module is used in Iphone, i intend to use it in a security cam project… tks

servicecell@yahoo.com.br

Could someone please send me the MT9D131 Developer guide?

We are trying to interface the camera to an Xilinx Spartan-3e FPGA for teaching purposes.

Thanks in advance.

r.hoeckmann@hs-osnabrueck.de

Hi Folks

Just noticed on the Aptina website that a new datasheet for the MT9D131 has been released dated March 2011 and an updated developers guide. Looking at the latest headboard schematic it looks like the sensor has gone to a single 3.3v supply. If anyone has the latest datasheet and developers guide can you please post a copy somewhere. Or please email me a copy. Thanks in advance.

pobox2day@gmail.com

Regards

Ian

iand2010au:
Hi Folks

Just noticed on the Aptina website that a new datasheet for the MT9D131 has been released dated March 2011 and an updated developers guide. Looking at the latest headboard schematic it looks like the sensor has gone to a single 3.3v supply. If anyone has the latest datasheet and developers guide can you please post a copy somewhere. Or please email me a copy. Thanks in advance.

pobox2day@gmail.com

Regards

Ian

Hello everybody,

I would appreciate too if someone could send me the latest datasheet to:

v1a9n8a6@gmail.com

Thanks and regards!

vjcro

why not upload it somewhere and post a link here

Hi Folks

Don’t know about you guys but am finding the task of interfacing to this sensor a bit tough. Good documentation but an amazing amount of registers and settings to look at and decide whether to change or not. I see some have had success which is encouraging and thanks to those who have posted register settings and initialisation code. Is anyone prepared to post or share a set of register and command values that works reliably. Preferable with JPEG output at full resolution. After looking through the guide and datasheet, it is not exactly obvious how some of these registers work or what they do. What is the advantage if any of using the spoof mode in JPG mode? Given the vast number of registers and settings that can be changed, it would be helpful to know which ones to leave at default and ignore. Then we would only have to deal with a smaller subset of registers to change depending on the output format, resolution etc. Looking at the JGP header code, wouldn’t this produce the same data each time assuming the resolution, restart intervals and qfactor remains unchanged for a given data stream. If so then it could be loaded into memory as a fixed block of data and then forget about adding the header code all together. Can anyone post the header file produced by the Micron code for say full resolution at default qfactor and restart interval.

I know lots of questions and maybe I’m off track a bit here and there but I’m trying to say with the KISS principle where possible and get this sensor going. Surely I’m not the only one out there struggling with this beast !

Thanks

Ian

Hi all,

Can anyone send me a copy of MT9D131 Developer guide pdf?

Thanks

My mail is: bill_w_chen@sina.com

Hi All

I’ve managed to capture a jpg file from the camera but seem to be having timing issues. Not sure if it’s hardware or register settings. The timing looks ok but I seem to be losing the last part of the data stream that contains the length and status bytes. I am using spoof mode. Tried different restart intervals but still similar problems. Attached is an example of a corrupted image. Tried many register settings based on the Aptina Devware register wizard but no real progress. I am using a AL440B FIFO buffer and a 3 input AND gate to enable the WE pin of the FIFO based on FV, LV and an enable signal from the uP being high. Appreciate if any one has some suggestions to try.

The distinction between the vertical bands of colour should be sharp. In your image they’re not - they’re fuzzy and coloured. I’m fighting the exact same thing. I suspect (not yet confirmed) that it’s a problem with the jpeg file header. I suspect the example source code in the aptina documentation to generate the file header isn’t quite right. Are you using that same code to generate the file header?

Ideally Aerospace would still be here to give us his jpeg header generator code. But it looks like it’s been a few months since he last visited.

There is certainly a problem with the aptina header generation code. The function DefineQuantizationTableMarker() produces incorrect results. I don’t know exactly why this is, but it clearly does. Replace the function from the developer’s guide with the following:

// Calculate and write the quantisation tables 
// qscale is the customised scaling factor - see MT9D131 developer guide page 78
int DefineQuantizationTableMarker (unsigned char *pbuf, int qscale, int format)
{
	int i, length, temp;
	unsigned char newtbl[64];			// temporary array to store scaled zigzagged quant entries

	if (format == FORMAT_MONOCHROME)	// monochrome
		length  =  67;
	else
		length  =  132;

	*pbuf++  =  0xFF;			// define quantization table marker
	*pbuf++  =  0xDB;
	*pbuf++  =  length>>8;		// length field
	*pbuf++  =  length&0xFF;
	*pbuf++  =  0;				// quantization table precision | identifier

	
	// calculate scaled zigzagged luminance quantisation table entries
	for (i=0; i<64; i++) {
		temp = (JPEG_StdQuantTblY[i] * qscale + 16) / 32;
		// limit the values to the valid range
		if (temp <= 0) 
			temp = 1;
		if (temp > 255) 
			temp = 255; 
		newtbl[zigzag[i]] = (unsigned char) temp;
	}
	// write the resulting luminance quant table to the output buffer
	for (i=0; i<64; i++)
		*pbuf++ = newtbl[i];

	// if format is monochrome we're finished, otherwise continue on, to do chrominance quant table
	if (format == FORMAT_MONOCHROME)
		return length+2;

	*pbuf++ = 1;				// quantization table precision | identifier for chrominance

	// calculate scaled zigzagged chrominance quantisation table entries
	for (i=0; i<64; i++) {
		temp = (JPEG_StdQuantTblC[i] * qscale + 16) / 32;
		// limit the values to the valid range
		if (temp <= 0) 
			temp = 1;
		if (temp > 255) 
			temp = 255; 
		newtbl[zigzag[i]] = (unsigned char) temp;
	}
	// write the resulting chrominance quant table to the output buffer
	for (i=0; i<64; i++)
		*pbuf++ = newtbl[i];

	return (length+2);
}

To go along with the code you need the following 3 lookup tables:

unsigned char JPEG_StdQuantTblY[64] = 
{
16,  11,  10,  16,  24,  40,  51,  61, 
12,  12,  14,  19,  26,  58,  60,  55,
14,  13,  16,  24,  40,  57,  69,  56,
14,  17,  22,  29,  51,  87,  80,  62,
18,  22,  37,  56,  68,  109, 103, 77,
24,  35,  55,  64,  81,  104, 113, 92,
49,  64,  78,  87, 103,  121, 120, 101,
72,  92,  95,  98, 112,  100, 103,  99
};

unsigned char JPEG_StdQuantTblC[64] = 
{
17,  18,  24,  47,  99,  99,  99,  99, 
18,  21,  26,  66,  99,  99,  99,  99,
24,  26,  56,  99,  99,  99,  99,  99,
47,  66,  99,  99,  99,  99,  99,  99,
99,  99,  99,  99,  99,  99,  99,  99,
99,  99,  99,  99,  99,  99,  99,  99,
99,  99,  99,  99,  99,  99,  99,  99,
99,  99,  99,  99,  99,  99,  99,  99
};

// this table is used for regular-position to zigzagged-position lookup
static unsigned char zigzag[64] = 
{ 
0, 1, 5, 6,14,15,27,28,
2, 4, 7,13,16,26,29,42,
3, 8,12,17,25,30,41,43,
9,11,18,24,31,40,44,53,
10,19,23,32,39,45,52,54,
20,22,33,38,46,51,55,60,
21,34,37,47,50,56,59,61,
35,36,48,49,57,58,62,63 
};

The inspiration for this code came from a user named Cristi Cuturicu at the website http://www.wotsit.org who posted some jpeg encoder / decoder code. I don’t really know exactly where the aptina code is “broken”, and I’m not too motivated to find out.

Using this revised function produces a far cleaner image. Take a look at the attached jpeg.

It’s not perfect yet, but it’s a big step forward.