Go Down

Topic: MT9D111 (2mp image sensor) with arduino (it can be done) (Read 2 times) previous topic - next topic


Jul 01, 2013, 01:34 am Last Edit: Dec 26, 2013, 10:10 pm by Mr_arduino Reason: 1
I have been making good progress on getting the MT9D111 to work with an arduino mega although I see no reason why it would not work on another type of arduino or anything else however I only tested it on the arduino mega. What I do is send part of the image to a tft screen that has a built in framebuffer and then read it back sending the data over serial or save the data to an sd card. This sensor has many more cool features but I have not had the time to utilize them all yet. I so far I have gotten the MT9D111 to output both rgb565 and yuv422. The MT9D111 supports dithering which is needed on rgb565 or else it looks even worse this is to make up for the lack of color bits. Yuv422 is much better quality. The bottom two images were taken with rgb565 the top image was taken with yuv422 mode

I have yet to work on jpeg output but it does support it.
You can follow this project for updates on what I have got configured.
Also here is a useful program that can convert raw (no header) image data to a png file
If anyone has any questions about the MT9D111 feel free to post theme here and I may be able to answer them.
Just for fun here is another image I got.


Hey, it's good to see that someone has the MT9D111 working with an Arduino. Are you using a FIFO to buffer the image data?

I'm using one of these things as well, although I gave up trying to get things working with the Arduino and went with the mbed platform.

Here's an 800x600 JPEG I was able to get off the device (JPEG is a bit tricky to get working, but seems pretty stable once things are set up right).

I do have a question, though. Does your device's EXTCLK run at 1/5 the speed in capture mode, as opposed to preview mode? That's what mine is doing, and I can't find any mention of that behavior in the datasheet or developer guide.

Edit: The image didn't show inline so I linked it


I have not tried jpeg yet I still have reliability issues in which the registers get randomly reset. (not sure why maybe because I am running the sensor slower than the minimum clock speed in the datasheet) What did you do to get jpeg working as for the clock speed running different in capture mode I have not seen that happen but I have not tested for it yet. As for a fifo I am not using one what I do is I send part of the image to a tft screen attached the arduino then I send it over serial then I do that for each part. In other words I have to break the image into parts because of lack of ram.


Actually, I was running the master clock way slower than the datasheet minimum at first and everything worked ok. Maybe a slow clock can cause instability on some modules though, I'm not sure. One possible issue is that you should use the driver variables whenever possible, because refreshing or switching the context will cause "shadow registers" (driver vars. that correspond to hardware registers) to overwrite the registers that they represent. For example, if you turned the camera on and changed some hardware registers immediately, they would get overwritten when the camera transitions from setup to preview mode, unless you changed the driver variables. Does that make sense?

JPEG compression wasn't too hard to get working - just a couple of register settings, although I wasn't able to figure out the "spoof mode" output option. Also, I'm pretty sure JPEG only works in context B (Capture mode), so you have to switch contexts before capturing the image. I'm not sure how you'll be able to capture a JPEG without a FIFO, though, since you can't just read in parts.

Another issue I had is that a qscale (quantization factor) higher than 12 will cause the image to get really messed up, so I can't compress the images as well as I would like.

These cameras are really interesting to work with, but I think you would have a lot more success with a more powerful microcontroller (or a FIFO, I guess).


Wow thank you. I was doing the exact opposite using registers instead of driver variables now I know my problem. Now I can see why the registers were getting overwritten.


Hello, i am working on a project to get one of those cameras to work. Could you both email me a schematic to see how you guys connected them. I will greatly appreciate it. I am new to electronics and this is a complicated topic.




Jan 10, 2014, 01:16 am Last Edit: Jan 10, 2014, 01:56 am by bear2004 Reason: 1
Hello all,

just got this module and noticed that it has a strange chip in LLC32 package. Aptina never manufactured MT9D111 chip in LLC 32 but rather in 64-ball BGA and/or as a bare die. What chip is really soldered on to this board? Even if it is possibly register-compatible with the original Aptina's MT9D111 sensor, is still has a different pinout and provides 2 strange signals: "Driver IN" and "Driver EN" ones, which the original sensors  don't have.
Would you mind to tell how are connections been made for your tests? Also, I guess it requires 2.8V supply (not 3.3) and expects same TTL (not CMOS) 2.8-compatible levels to drive it's XCLK pin?


Actually I've found a partial answer to my question myself: it looks like it could be Chinese-made PCB carrier for Aptina-s chip, with the reduced pins and formed as pseudo-LCC32 pinout.  For example:

However, still the question is - what are "Driver IN/EN" signlas for? Should they be left unconnected?


Can i see how to Connect all the cables and some example in a sketch?... id like to see that, PLEASE thanks!...

you can email me that info if possible, a pic of the connection made of the MT9D111 Camera to Arduino (I got mega) and a Sketch which shows me how does it work, Thanks!



Great work, first of all.

I would like to use your code to interface Mt9D111 with uC to get JPEG images,

I can see JPEG capture functions implemented in your code,
I would like to ask if these jpeg functions complete, functioning properly?

And also, may you give some more info about your design,
like MCLK freq, PLL settings and if possible may you share schematics?

Thanks in advance



Thanks for sharing this!

I'm wondering if it's possible to configure MT9D111 to send half of the byte (using lines D0-D3) instead of full byte (D0-D7)? I need to capture the still photos, not the video and that would save the GPIOs . The LCD driver hd47780 can work that way for instance.


Go Up