I managed to read the right values, but after some delay, or for example - I reset the camera, read some registers’ values, write my configuration, read the same values again, and I get almost all default values (no effect from my configuration, only the seq.state becomes ‘changing to capture’). When I start the same read-write-read process again (without resetting the camera) I get the wanted registers’ values on the first read.
I guess it’s all about timing…
How’s your struggle with timing by the JPEG image doing?
We’re designing a wireless image sensor node for a WSN. We want to configure the camera by uC, capture the image, collect it with FPGA, store it in SRAM, and send the image (compressed one) to the coordinator node over ZigBee in sequential packets.
Another tech working on the problem thinks our timing problem comes from the FIFO buffer we are putting our image through. It needs an extra clock cycle after Frame_Valid and Line_Valid go high before it can start storing bytes. We may need to add some more hardware to our design.
We are trying to develop the camera for a Pico-satellite, a small 10x10x10cm cube. We want high res pictures, but we need them to be compressed since our transfer speed to the ground station is limited.
I’ll let you know our progress.
Oh also, here is my proof of success :). This is a thumbnail of one of our good images, so the timing problem doesnt show up.
Yes, we also find the FIFO buffer to be a potential problem, but haven’t got anything in particular to deal with it by now.
I notice 2 or 3 small stripes on the image (one green, one black, one blue), if I’m not mistaken. We also had that in our previous design, and they were longer sometimes. What about that?
Actually the first couple pictures we took had much longer stripes, but I got rid of them by increasing the frequency of the restart interval (jpeg.restartInt). When I had this value set to zero, there were lots of stripes, I set it to 16 and got fewer stripes, but they were still long. The picture I posted had this value set to either 1 or 2. Note, the header had to be changed accordingly as well.
I managed to configure the camera successfully and get the JPEG image (with the register configuration I wrote it worked for us before). I still have troubles with timing, it takes a lot of time for the registers to accept the configuration. I’m not sure yet is it because of the SW (stack on the microcontroller) or the HW (we have the camera connected with a flat cable about 15 cm long).
Anyway, I changed the restartInterval to 0x0002 and got a couple of squares (short stripes), similar as you. Thank you for that suggestion
Did you manage to get rid of them or do you think it can’t be avoided?
I am in the same boat as Jan who posted on Jan 22. I am interested in using this product (for an undergraduate school project), but I haven’t heard back from Aptina after I requested the Developer’s Guide document quite some time ago. I would greatly appreciate it you could share this document with me.
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.
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.
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.
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.
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.
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.
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.
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.
<LINK_TEXT text=“http://www.freeimagehosting.net/uploads … f8098e.jpg”>http://www.freeimagehosting.net/uploads/th.6b1cf8098e.jpg</LINK_TEXT>
