SparkFun Forums 

Where electronics enthusiasts find answers.

Have a good idea for a new product for SFE or Olimex? Let us know!
By Aerospace
#96669
Thought I would update on my progress...

Everything seems to be working fine. The camera takes full size, full resolution JPEG pictures with no noise. I have it set up on a custom breakout board with a PIC microcontroller, and I send it commands from a GUI written in Visual Basic 6. I'm now just cleaning up the GUI and working on understanding some of the more complex functions of the chip (windowing, contrast and gain control, capturing uncompressed images, etc). I'm also more then happy to share what I've learned, just let me know.
By rmann
#96881
[quote="Aerospace"]Thought I would update on my progress...

Everything seems to be working fine. The camera takes full size, full resolution JPEG pictures with no noise. I have it set up on a custom breakout board with a PIC microcontroller, and I send it commands from a GUI written in Visual Basic 6. I'm now just cleaning up the GUI and working on understanding some of the more complex functions of the chip (windowing, contrast and gain control, capturing uncompressed images, etc). I'm also more then happy to share what I've learned, just let me know.[/quote]

Aerospace,

I'm looking to develop a controller with a camera, and I've been checking out the sparkfun options. I came across this forum, and would like to know how you managed to interface a camera like this to a PIC. I haven't used a PIC24, and these days use an Atmel ARM SAM7X. How do you interface the sensor you're using? I read this thread, but I'm not clear on how you set up the basic interface.

Thanks for any help!
By Aerospace
#96935
rmann,

I used an Averlogic 440b FIFO buffer in between the camera and the PIC. I had to use a little bit of glue logic (Flip flops to make the timing between the camera and the FIFO compatible and an AND gate going to the enable pin on the FIFO write), but now i have the PIC issue the snapshot command to the camera, read a register to see when its in "capture" mode, then set a FIFO enable pin and wait until the camera exits capture mode. Then I can just read the frame out of the FIFO with the parallel port on the PIC and send it to my PC via RS-232.
By rmann
#96936
[quote="Aerospace"]rmann,

I used an Averlogic 440b FIFO buffer in between the camera and the PIC. I had to use a little bit of glue logic (Flip flops to make the timing between the camera and the FIFO compatible and an AND gate going to the enable pin on the FIFO write), but now i have the PIC issue the snapshot command to the camera, read a register to see when its in "capture" mode, then set a FIFO enable pin and wait until the camera exits capture mode. Then I can just read the frame out of the FIFO with the parallel port on the PIC and send it to my PC via RS-232.[/quote]

Okay. I'm looking at building a board around the Atmel AT91SAM3S, which (as I understand it, have yet to confirm) has a PIO parallel input capture capability. I'm hoping I can use that to get the data in directly. It also has an external memory interface, which I will likely need to hold an entire frame of data. We have a very slow data link in this project, so I just want to send individual frames at whatever rate I can achieve.
By Aerospace
#96946
rmann,

That could work well, although you will probably have to run your AT91SAM3S >45 MHz. I think the max speed is 64 MHz so that should be fine. But the camera has a minimum clock speed of 6 MHz. It allows you to do some clock division for your output data, so you could get it down to around 3 MHz. Then you could probably write efficient enough code to see if the data is valid, read it through the PIO port, and save it to your external memory (if you had that connected through a parallel port as well) in 15 clock cycles. 15*3 MHz = 45.

However, this could cause some problems as the camera outputs data through an internal FIFO buffer, and if this overflows your frame will be lost. Basically this means that while a data rate of 3 MHz is possible in theory, it might not actually be possible in practice. If you can't slow it down past even 6 MHz, say, then you will only have 10 clock cycles (10 * 6 = 60 MHz) to store the data, and you will be pushing the limits of the MCU. Also, if power consumption is a problem this might not be ideal. Just some food for thought before you get started.
By rmann
#96947
Thanks for the considerations. I wonder if I can't take advantage of the DMA the MCU has?

I'm drifting more toward a solution with eASIC's H.264 encoder anyway, if I can get them to pay me any attention.
By Aerospace
#97653
@51mmz

To be honest, I'm not sure what finally fixed it. The VB code I was running at that time was messy, and likely had some bugs in it (esp in the serial comm section which is how I was retrieving the data from the camera). It has since been cleaned up considerably and im much more confident it is bug free. However we also revised our breakout board for the camera and added some glue logic to fix timing issues between the camera and the FIFO buffer. This was definitely causing noise in our pictures and needed to be fixed, but I'm not sure if it was the exact cause of the skew I saw. I also had to fix our PLL parameters, and I found that adding a restart interval into the data cleaned up the image a lot.

Are you having this issue as well? If so, what set-up are you using? While I'm not sure what finally fixed my problem I could definitely give you suggestions on where to start if you're seeing the same thing.

edit to add: I don't think it was blanking related as I've been leaving those registers at their default values.
By actaylor
#100114
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
By Aerospace
#101132
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.
By danutstanciu
#101752
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.
Last edited by danutstanciu on Mon May 31, 2010 12:26 am, edited 1 time in total.
By ashura
#101896
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
By Mohammadi
#101930
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