Micron/Aptina MT9D131 JPEG Camera

Archive New Product Ideas
61

Thanks Frank

I will try the change to the header code. I always thought the data was corrupted in some way and hence the ‘noise’ in the vertical color bars, never suspected the header code. I had just about given up on this sensor so am grateful for your help. I have also found that the sensor is very sensitive in the electrical connections with pxlclk, lv and fv. I am interfacing to 3.3v logic and have tried inserting 47ohm resistors in series with each of these signals as per the Aptina headboard schematic. Has anyone any experience or problems in this area ? I may have to use level translators to see whether it solves the problem. Without a 47ohm resistor in the pxlclk line, the sensor ‘hangs’ and won’t even communicate over I2C which is strange. But this sensor nevers ceases to amaze me with the inherent difficulties of getting an image out of it.

Will let you know how it goes.

Regards

Ian

62

I’ll admit the last thing I’d been suspecting was the header. I had expected the Aptina code would be correct. Just goes to show - suspect everything! :slight_smile:

I’m using 1.8V I/O for the sensor so I can’t offer any experience with 3.3V . I have noticed that the sensor does have slew rate control for the output pads - have you tried changing that?

I’ve seen that the sensor won’t respond to I2C commands while the PLL is settling (registers 0x65, 0x66 and 0x67). After changing those registers I wait for a while (10 ms in my case) before continuing.

Have you looked at your signals on a scope? Normally series resistors are used to deal with ringing and overshoot etc. If you don’t have those things but the series resistors are making a difference for you, that may point to a marginal timing problem. The blocks of grey / hash in your image clearly point to a timing problem as well.

63

I tried the modified header code, the image improved but for me the big issue is the noise/errors in my image. The Restartint improves things a bit but they remain. I’ve looked at the signals on my USB scope but am limited with speed to look at too many signals at once. But the signals look clean and the timing looks ok. I’ve learned not to trust thouigh what you see on these USB logic analysers though so it may still be a problem. I’m using an AL440B FIFO to buffer a frame of data so my problem may also reside there, especially with timing, although it looks ok. Aerospace mentioned he used some additional glue logic with his FIFO (same one), so that may well be my problem. I note that the camera I/O voltage is at 2.8v and so a logic 1 is at VDDQ-0.4v which would be 2.4v with VI/O at 2.8v. For 3.3v logic, the typical VI/P voltage min is around 2v so it should be ok but this may be a problem, don’t know.

It is difficult to troubleshoot this problem at you can’t guarantee a particular data stream coming it. I have thought about loading the available RAM in the sensor with a known string of data and then seeing whether I can send that out. At least then I can determine more closely where data is being corrupted. How repeatable do you think the test pattern would be ?

Regards

Ian

64

frankvh: I also tried the new header and here are my findings.

I made a routine that saved the same image twice, one file with your suggested header with your tables and a second file with aptina’s header and their tables. Note that I did not take the picture twice, only once to 2 separate files. The result was the same header info was generated. No difference in image quality at all.

My conclusion is this: Your suggested header has a 3rd table to align the data, and aptina’s header has a rearranged JPEG_StdQuantTblY and JPEG_StdQuantTblC into a linear method. This resulted in the same data.

Anyone else get this result?

65

That’s interesting. So you’re saying you’ve seen no difference between the Aptina code and my code in terms of header generation. But I’m certainly seeing a difference. I wonder if the reason is the different C compilers we’re all using. Some folks will see a problem and some won’t.

66

Can anybody help me to figure out, how to lock JPG data in MT9 RAM and read it with small portions ?

I have PIC18 with 58Mhz ,3.8K memory.

Is there any way to do it without adding a memory?

67

I don’t think you can. The internal memory of the sensor isn’t large anough to hold an entire image, so you have to read it all out. That’s why people in this thread are using FIFOs. Or use a processor with enough memory (either internally or externally).

Remember also that the image sensor supplies the clock when outputting data, so whatever method you’re using to read the data from the sensor has to sync up with the pixel clock.

68

ok. I went the other way. I ve baught PIC32 max32 board and connect it to MT9D131. PIC32MX785 has 128 kb RAM .

So I ve got some “photo” it seems working. But , apparently I am stupid I dont know hot to connect quantization table in header file and sensor. Do I need to download it from the sensor via indirect registers or not?

69

I ve got it work. Ok. Thx

70

Hi there,

I dont understand how to determine the preview size. It gives me 960 000 bytes. Which is good for 800x600 for context A . Bit for 80x60 is too much.

I set

  1. VAR = 7, 0x03, 0x00A0 // MODE_OUTPUT_WIDTH_A

  2. VAR = 7, 0x05, 0x0078 // MODE_OUTPUT_HEIGHT_A

  3. VAR8 = 7, 0x7D, 0x0020 // MODE_OUTPUT_FORMAT_A

  4. VAR8 = 1, 0x03, 0x0005 // SEQ_CMD (refresh in the new settings above)

and it doesnt affect.

Should I take first 9600 bytes from 960 000?, or how?

There is no any information in documentation.

71

Hi, I like to get started working with the MT9D131. Where can you purchase the camera in single quantities? Digikey requires an entire tray and is non-stock. Thanks!

72

Hello everyone. Sorry for my language but I am not from english speaking country. I have big problem with mt9d111 camera. I can’t switch context from A to B. I have no idea what I have been done wrong. I resets camera by software reset. I put 8mhz clock into camera and setting

seq.captureParams.mode[1]=1

then I change resolution on context B. Next I set seq.cmd=1

I get image but with resolution with is set on context A. Could you help me ?

If I change another resolution on context A The image will have the same resolution as I set.

73

I’m using DMA to get data out of the camera and store it into my 64k of memory using a stm32. I was able to get rgb data working after some time but i’m having a hell of a time with the jpeg.

If someone could answer these questions it would save me tons of time. I’m developing a small inexepensive robot btw, you can see it on my site zonemikel.com

1.) what do i put for restart_int and qscale for the constructor

CreateJpegHeader(char *header, int width, int height, int format, int restart_int, int qscale)

2.) after i’ve generated the jpeg header can i just append the same one to any image created by the camera with the same settings ?

3.) when i call capture image what do i need to do after that to “accept” the image, do i need to rewrite some registers so that the camera knows i’ve accepted the jpeg ?

  1. Lastly, call the “CAPTURE” command:

• seq.cmd = 2 // ID = 1, Offset = 0x03

4.) I’m Using areospace’s registry settings from page 2 of these forums, I changed the size to 128x96, and turned on binning like it says in the dg. is that all i need to change ?

If the image size is less than or equal to 800 x 600, binning mode with 1ADC must be

enabled by:

• R0x20:0[10] = 1 and R0x20:0[15] = 1

5.) if i’m using test mode 7 to get just a white background should my jpeg data always be the same ? (for testing)?

6.) does this work ? I seem to still get a clock on invalid data ? Wouldnt i still get a clock when it goes back into preview ? Can someone explain how we go from preview to capture and what is the purpose ? Page 2, reg 13/0x0D bit 2

Enable pixel clock during invalid data: When this bit is set, the pixel clock runs continuously

while FRAME_VALID is asserted but LINE_VALID is de-asserted. When cleared, it causes the

pixel clock to be active only when valid JPEG data are output. Disabling pixel clock during

LINE_VALID de-assertion is not support in spoof frame.

With all of these questions and the dma/i2c thrown into the mix it becomes a mess trying to figure anything out.

This is what i do, or at least i’m trying to do.

  • set all registry settings

  • enable dma triggered by pixclk (only on valid data)

  • send capture command = writeDriver(0x01, 0x03, 1, 0x02); //Calling Capture

  • wait for jpeg status to show data available = while(CAM_ReadReg(0x02) == 0) // on pg2

  • disable dma, clean up camera registers

  • extract valid jpeg image from dma memory buffer

  • send to computer, append header, show

Thanks for any help on any portion of these questions, code would be awesome !

74

Bump. Does anyone have the code to set registers and take an image off of this device ? I figured out the header does not have to change thanks to frank.

Is there another camera with more community support i should look into ?

75

Hi,

I’m using MT9D111 sensor and I have problem with writing ROW_WIDTH (R0x03:0) register value. I tried to write many other registers, also COL_WIDTH (R0x04:0) and these updates take effect (value is stored), but ROW_WIDTH no. When I write that register, the value is stored for some little time and then returns to previous value. Datasheet says that default value is 0x4B0 but I get 0x3B0, also after reset. Is someone has the same problem or know how to solve it?

76

Hi Johns,

I found a interest web site http://www.arducam.com/camera-modules/2mp-mt9d111/

The MT9D111 is much like the MT9D131 in some ways.

Wish this will help you.

77

Hi everyone!

I am using MT9D111. I did not have a problems with BMP, but JPEG is like a nightmare. I tried every init codes available on google. I set dimmensions to 100x100px but received frame has more bytes as DMA(stm32) could transfer. Could someone send me running code? (kakamistrz1990@o2.pl)