Micron/Aptina MT9D131 JPEG Camera

Have a good idea for a new product for SFE or Olimex? Let us know!

Moderator: phalanx

Aerospace
Posts: 27
Joined: Thu Jun 04, 2009 4:25 pm
Location: Los Angeles

Micron/Aptina MT9D131 JPEG Camera

Post by Aerospace » Mon Nov 30, 2009 9:00 am

Hi all,

I have been following a similar thread on here that is looking at a JPEG camera from Toshiba, but due to poor documentation, I have decided to try my luck with the MT9D131 JPEG camera from Aptina. The camera is easily available off the shelf and has great documentation.

I am building a camera system from scratch, and so far I am controlling the sensor with a PIC18f420 microcontroller and buffering the data through an AL440B FIFO chip from averlogic. I am curious if anybody has used this sensor before, b/c when I look at the data that I get while running JPEG compression, it doesn't contain any of the standard JPEG header info.

Any help would be greatly appreciated. Thanks.

vjcro
Posts: 13
Joined: Sat Dec 19, 2009 5:16 pm

Post by vjcro » Sat Dec 19, 2009 5:44 pm

Hi Aerospace,

we use MT9D131.
As it's said in the MT9D131 Developer guide: 'JPEG data stream sent to the host does not have a header'. You have to create it and attach it to the file you get from the camera in order to get the complete JPEG file. You have the code at the end of Developer guide.

I have some problems with camera configuration. Uncompressed image works fine. But when I set the registers in order to get JPEG image, I get a really small file (about 10kB). Could you please write your register configuration that gives you a compressed image? What's the input clock you provide to the camera?

Thank you in advance.

dah
Posts: 2
Joined: Tue Dec 22, 2009 11:54 am

MT9D131

Post by dah » Tue Dec 22, 2009 12:01 pm

vjcro,

The person working on this is on vacation. He will get back to you soon though. I work with him managing the project. Can you say more about how you go the uncompressed image out of the chip? I am not sure we have been that far.

Also, we ordered a $1200 Aptina development board with software. That software came with examples that run off the Blackfin processor which controls the camera. However, the source code provides the register camera register settings. Do you have or need this code?

vjcro
Posts: 13
Joined: Sat Dec 19, 2009 5:16 pm

Post by vjcro » Tue Dec 22, 2009 1:03 pm

Hi,

we connected the PCB with camera chip to a PCB with a FPGA and RAM. So, the FPGA collects the image and stores it to RAM.

We also ordered the devcamera from Aptina in order to make our development easier. We downloaded from their website Devware with generic suite. We didn't find any examples. We don't use Blackfin processors though, but I would appreciate if you could send it to me. It could be useful, maybe.
We wanted to check the register states in Dewvare. But we noticed that some (quite important) don't match with the datasheet instructions.

We also tried to connect our PCB camera with Aptina's controller board (we designed an adapter PCB), but Devware doesn't recognize our camera.

As you can see, each step in the debugging process has given as more headache :(

I hope we can compare our experiences and find out some useful stuff.

dah
Posts: 2
Joined: Tue Dec 22, 2009 11:54 am

Post by dah » Mon Dec 28, 2009 11:47 am

vjcro,

We can talk the week of 1/4.

Aerospace
Posts: 27
Joined: Thu Jun 04, 2009 4:25 pm
Location: Los Angeles

Post by Aerospace » Mon Dec 28, 2009 1:05 pm

vjcro,

Hi, I'm the one that has been working with the MT9D131.

1. We use a 10 MHz input clock, 3 V p-p

2. Our register settings mostly match the ones used in the Devware software. I was a little confused at first when looking at them, but I am fairly certain that the SOC registers are updated automatically from the virtual drivers when the context is changed. I had to look at those and not the actual registers, since I could only ever see them for Context A. I am going to be in the office tomorrow and will post the settings I use. But note, I haven't gotten a valid picture yet (not sure if its the header or invalid data).

3. Can you post a link to the Development guide you mentioned? I have not seen this and would like to look at the header generation code you referenced at the end of the guide.

4. What register settings did you use to get uncompressed images? (I have been focusing solely on JPEG, and getting a valid uncompressed image would help debug, however I don't want to reinvent the wheel if I can help it :D )

vjcro
Posts: 13
Joined: Sat Dec 19, 2009 5:16 pm

Post by vjcro » Sat Jan 02, 2010 7:49 am

Hi Aerospace,

we also have a 10 MHz input clock and use PLL.
The Development Guide is not available on the web, you have to log in to Aptina's pages and request a permission to download it. However, if you want, I can e-mail it to you, just write your e-mail address.

I will post the register settings for uncompressed image ASAP (probably on Monday).

P.S. Best wishes for the new year!

vjcro

vjcro
Posts: 13
Joined: Sat Dec 19, 2009 5:16 pm

register configuration for uncompressed image

Post by vjcro » Mon Jan 11, 2010 4:50 pm

Hi, Aerospace,

it took me a while longer to write here again, sorry.

Here are the register settings we use to get a 1000x1000 uncompressed still image:

R0x0A:0 = 0x0002
R0x0D:2 = 0x0007
R0x0A:2 = 0x0001
R0x09:1 = 0x0009
seq.captureParams_mode = 0x02
mode.mode_config = 0x0030
mode.output_width_B = 1000
mode.output_height_B = 1000
mode.crop_X0_B = 300
mode.crop_X1_B = 1300
mode.crop_Y0_B = 100
mode.crop_Y1_B = 1100
seq.cmd = 2

Please let me know does it work for you and what's your progress.

vjcro

Aerospace
Posts: 27
Joined: Thu Jun 04, 2009 4:25 pm
Location: Los Angeles

Post by Aerospace » Tue Jan 12, 2010 12:09 pm

Hey vjcro,

Sorry to get back so late, I was out for the holidays.

Thanks for the register setttings. Im a little confused, though. doesn't
seq.captureParams_mode = 0x02 set it to capture video?

Also how many bytes were your still images (so I know how many to grab from our FIFO) and what format is it? Bayer 10 bit, RBG565, etc? And what program did you use to view the images after capture?

Here are the settings I used for JPEG capture (some just verify the defaults:


R0x05:0 = 0x0204 'H-blanking (context B)
R0x06:0 = 0x0020 'V-blanking (B)
R0x09:0 = 0x0007 'Shutter Width
R0x0A:0 = 0x0131 'pixel clock timing
R0x0B:0 = 0x03BB 'Extra delay
R0x20:0 = 0x0300 'Read mode for context B
R0x65:0 = 0x2000 'Clock control (enable PLL)
R0x66:0 = 0x4F07 'PLL params

'Color Pipeline (page 1)
R0x08:1 = 0x01F8 'Pipeline control
R0x0B:1 = 0x00DF 'Enable Internal Clocks
R0x09:1 = 0x000A 'Disable output bypass (output JPEG)

'JPEG + FIFO (page 2)
R0x0A:2 = 0x0000 'Disable JPEG bypass

Aerospace
Posts: 27
Joined: Thu Jun 04, 2009 4:25 pm
Location: Los Angeles

Post by Aerospace » Tue Jan 12, 2010 12:22 pm

Here are the driver variable settings I used:

seq.captureParams_mode = 0x00

seq.captureParams_numFrames = 0x01

mode.outputWidth_B = 1600 (0x0640)

mode.outputHeight_B = 1200 (0x04B0)

mode.mode_config = 0x0010

mode.FIFO_config0_B = 0x0046 (adaptive clk on, no spoof)

jpeg.format = 0x00

jpeg.config = 0x0034

jpeg.restartInt = 0x0000


The restartInt I found is very important. If this variable is set to zero you must remove the restart interval section of the JPEG header. Else you must make sure that the value in the header matches the value you put in this variable (I believe the default is 0).

I am able to get garbled images with these settings, with no consistency, however I don't think the problem is with the sensor but rather the architecture I designed around it. Im curious to hear how this works for you, since you have already proven that your architecture works.

Also note, the number of bytes of JPEG data the sensor produced for the last frame is available in the status registers (R0x02:2 and R0x03:2 I believe). You said your files were small, but do they at least match the size found in these registers?

vjcro
Posts: 13
Joined: Sat Dec 19, 2009 5:16 pm

Post by vjcro » Tue Jan 12, 2010 1:11 pm

Aerospace wrote: Im a little confused, though. doesn't
seq.captureParams_mode = 0x02 set it to capture video?


You're right, but it wasn't actually so important for our implementation, because we turn the camera off after the first frame (after FV signal falls). But I will change it, to make things more clean.

1000x1000 image is 2 000 000 bytes, format is YUV, 2B per pixel, 8 bit output. Quite a lot, I know, but you can also capture a smaller image just for verification.
The image is collected via RS232 and we have a Matlab script to convert the .txt file from YUV image to RGB and then we can see the image on screen.

We also noticed the importance of restartInt.

Our main problem is that we implemented I2C register configuration in FPGA. But we didn't implement the I2C reading. That's why we can't check state of any register. We kind of hope to have made the right configuration... The next step for our development is to implement I2C configuration (and registers verification!) in a microcontroller and only leave image collection to the FPGA.

I'm quite busy with some other stuff these days, but I have to continue the work on the camera asap. I'll study more carefully your registers and everything else you wrote and then I'll be back in touch.

Aerospace
Posts: 27
Joined: Thu Jun 04, 2009 4:25 pm
Location: Los Angeles

Post by Aerospace » Tue Jan 12, 2010 1:47 pm

Sounds good, let me know what you find out.

Also, would you mind sending me the Matlab script? I can pm you my email address if need be. I am trying to eliminate all possible sources of error, so running a script thats already been used would help speed things along a lot.

Thanks again for all the help.

vjcro
Posts: 13
Joined: Sat Dec 19, 2009 5:16 pm

Post by vjcro » Tue Jan 12, 2010 3:03 pm

No problem, send me you e-mail address in pm and I'll send it tomorrow.

Aerospace
Posts: 27
Joined: Thu Jun 04, 2009 4:25 pm
Location: Los Angeles

Post by Aerospace » Thu Jan 21, 2010 2:16 pm

Update:

I was able to obtain valid uncompressed images using the settings you posted (w/ smaller image sizes)

I tried switching to JPEG, but had no luck. I am generating my header based off of the sample code in the developer's guide (except for the Huffman tables, I am just using what I think are standard values, but updating this is my next step). I am able to grab the right number of bytes from the camera though (based on registers 0x02:2 and 0x03:2).

Thats all for now, not sure if the problem is in my header or my data, or how to check this. Any thoughts?

vjcro
Posts: 13
Joined: Sat Dec 19, 2009 5:16 pm

JPEG configuration

Post by vjcro » Fri Jan 22, 2010 8:03 am

Ok, than it turns out your HW surrounding is more stable than ours for now.
I've been getting 960 000 large files lately (with this configuration I wrote and also for a smaller image). I suppose the problem is I2C, so I've been dealing with that these days. It takes me longer cause I'm using a Bitcloud stack, and I didn't figure completely out yet how to get I2C going on it.

This is the configuration we've used earlier to get JPEG image:

R0x66:0 = 0x1801 //PLL setup, M = 24; N = 1; P = 0; f_in = 10 MHz, f_out = 60 MHz
R0x67:0 = 0x0000
R0x65:0 = 0xA000
R0x65:0 = 0x2000
R0x0A:2 = 0x0000 // Disable JPEG encoder bypass
R0x09:1 = 0x000A //DATA output - use FIFO

seq.captureParams_mode = 0x00 //capture still image
mode.mode_config = 0x0000 //Use JPEG compression

-- JPEG config
jpeg.qscale1 = 0x89
jpeg.restartInt = 0x0020

-- Image cropping and scaling
mode.output_width_B = 900
mode.output_height_B = 900
mode.crop_X0_B = 350
mode.crop_X1_B = 1250
mode.crop_Y0_B = 150
mode.crop_Y1_B = 1050

-- change context to capture
seq.cmd = 2

At some point we managed to get a solid image (in a sense that you could see the proper scene), but with black lines in random places, as if something went wrong with JPEG. For some reason, we can't get even that any more.
So, try this (maybe it'll need some adjustments to your system) and tell me what you get.

Post Reply