http://www.sparkfun.com/commerce/produc … ts_id=8667
The datasheet is literally rubbish… I can’t find anywhere anyone that would share how to use it and nobody here seems to help…
Could you please make a more detailed datasheet application notes and provide buyers with more info? Or am I supposed to buy 10 of them and roast the one after the other till I figure out how to use them?
Not sure what the specific problem you have with the camera, but the datasheet is better than the average datasheet for an asian market component. The timing diagrams are clear enough, the camera uses a standard bus for control, and implementing an 8bit parallel bus is easy. You may find the report from the [US Army Research Laboratory interesting. Googling the item’s name along with “application notes” is a wonderful thing.
A quote from the report I mentioned:
There is only one command that must be sent to the camera
for it to begin sending images—0x02. After issuing this command, the camera uses the vd, hd,
dout, and dclk pins to transmit frame data. A transition from low to high on the vd pin indicates
a new frame, while a transition from low to high on the hd pin indicates the beginning of a
scanline. For every square waveform on the dclk pin, while both the vd and hd pins are high,
there exist 8 bits of pixel data on the dout pins.
](http://www.dtic.mil/cgi-bin/GetTRDoc?Location=U2&doc=GetTRDoc.pdf&AD=ADA499618)
Cant argue with that but it is not enough information. Also the diagrams are not understandable at least by me. Am I supposed to
have finished a university to be able to understand them(I am still student)? While looking at other camera products the documents
were enough to understand how to connect them to my board…
Because this product is sold in Sparkfun.com and not on sparkfun.jp could sparkfun create a detailed documents for this product?
d4n1s:
Am I supposed to have finished a university to be able to understand them(I am still student)?
Unfortunately yes. These camera modules were never designed with the hobbiest in mind. They are intended to be used by larger companies with dedicated engineering resources. Sparkfun probably found an inexpensive source of the modules and decided to make it available for anyone willing to put in the effort to get them working.
I highly doubt that Sparkfun would invest the time to rewrite a 3rd party’s datasheet on a $10 part, not to mention they could run into copyright issues for attempting to do so.
-Bill
Is there anyone influenced by the altruistic ideas of our society willing to “waste” some minutes from his free time to explain me the info in the datasheet?
Have you searched to see if anyone else on this forum has used it?
yeah they have used it and I have seen a couple posts but they don’t explain anything on how they used it…
What don’t you understand in the datasheet? Timing diagrams? Register descriptions? Interface?
Timing diagrams are easy. They show you a simplified view of what the communications bus would look like under an oscilloscope/logic analyzer. Look at Dclk and see how it compares to all the other signals.
I’m not sure how comfortable you are with C or embedded electronics, or what processor you want to use with this camera, so I can’t really discuss the interface and registers. If you plan on processing the image on your micro, keep in mind that you will need something with some serious crunching power, and something capable of running a clock speed well above your parallel data bus clock. The report I linked to has a nice description of the image format, and other eccentricities of the datasheet, but if you want higher resolution/compression, I’d agree with the report in suggesting another camera module with built in compression.
http://arduino.cc/en/Main/ArduinoBoardMega2560
I have enough c++ knowledge to handle the incoming data.
What I don’t understand from the datasheet is, what each pins does? Are all pins digital? While making a logic level converter I don’t know where to put the resistors… Will I connect the camera on digital or analogue input on the board?
There is a table where it says YUV and RGB dataout pints description
below RGB there are some columns with names 1st and 2nd what are they supposed to mean?
I have already ordered the board and the camera…
Will I be able to handle pixel by pixel on the fly using this board? Meaning that I will send some current to the camera and than expect my board to be bombard with info.
If you can’t see that all the signals are digital, perhaps you should give up now.
Could u answer at the rest of the questions then?
So you are a noob and you complain that you don’t understand stuff and that’s somehow sparkfun’s fault. Maybe you should research more before trying to interface a cam module that wasn’t built for noobs.
the reason datasheets were created was to explain to noobs like me how to use their product. Or else they can keep the cameras for themselfs. There is no reason to sell a product without a manual or a manual that lacks of information. If you can understand what each pin of the camera does I would be glad to explain me. And if you can understand whether the camera output is digital or analogue be my guest to quote from the datasheet.
Toshiba sells TVs with manuals, fridges with manuals and even remote controls with manuals, things that even a retarded could use
without a manual, however they don’t publish a complete manual, or an understandable manual for such complicated machine. You can claim that it is my ignorance of computing systems to understand how this manual works, but the problem of my understanding
skills exist only on the specific datasheet from all of the datasheets I have read so far on sparkfun.
I would rather see sparkfun or someone explain me (or even fill in missing information from the datasheet) the camera application than posting anti-arguments.
PS my questions were still not answered.
If you read the data sheet properly you will see that the signals are all digital. You will also see their exact electrical specifications.
Those two columns for the RGB data are obviously for consecutive reads of the parallel data bus, giving RGB565 (5 red levels, 6 green levels and 5 blue levels). The YUV data need four consecutive reads. Why couldn’t you work that out for yourself?
Data sheets are written for experienced designers, not for someone who hasn’t a clue about electronics. You say you are a student, some studying might be a good idea!
d4n1s:
the reason datasheets were created was to explain to noobs like me how to use their product. Or else they can keep the cameras for themselfs. There is no reason to sell a product without a manual or a manual that lacks of information. If you can understand what each pin of the camera does I would be glad to explain me. And if you can understand whether the camera output is digital or analogue be my guest to quote from the datasheet.Toshiba sells TVs with manuals, fridges with manuals and even remote controls with manuals, things that even a retarded could use
without a manual, however they don’t publish a complete manual, or an understandable manual for such complicated machine. You can claim that it is my ignorance of computing systems to understand how this manual works, but the problem of my understanding
skills exist only on the specific datasheet from all of the datasheets I have read so far on sparkfun.
I would rather see sparkfun or someone explain me (or even fill in missing information from the datasheet) the camera application than posting anti-arguments.
PS my questions were still not answered.
You’re confusing electronic components with consumer electronics. If you can’t tell the difference, you shouldn’t even be here. This is not a fridge or a washing machine, this is not made for “retards” as you say, this is not for everyone to use. It requires studying and research, do it. In the end as a reward you get a warm and fuzzy feeling of accomplishmed 
Please keep the conversation civil.
Camera modules are notorious for having poor data sheets and while this one is perhaps better than most it’s quite dense.
You might want to look at a few of the links (at the end of the linked section) about how to read to read datasheets on my site: [How to read datasheets
–Philip;](http://code.rancidbacon.com/Electronics#PartsSourcesIdentificationandDatasheets44)
follower:
Camera modules are notorious for having poor data sheets and while this one is perhaps better than most it’s quite dense.–Philip;
I’d extend that by saying any component not designed for use in the hobby electronics market has a more complex datasheet. Do you need a degree in engineering to read one of those datasheets? No. (How would I know? I don’t have a degree, and I’m not currently a student.) Does it take patience? Always.
The camera interface is as follows:
In RGB mode the camera sends 2 bytes (16 bits) per pixel. These 2 bytes are encoded using, as leon mentioned, a 565 sequence. The first 5 bits are the red value. The next 6 bits describe the Green channel. The final 5 bits describe the blue channel. (Leon already mentioned this, but it bears repeating.)
The camera spits out the data in relation to Dclk. The vd line tells you that there’s a new frame (image) available. The hd line tells you that a new scan line has started. When both lines are high, the data will be clocked out of the D0-D7 lines. Every time the clock transitions from low to high the next byte is available. (It’s a pretty standard clocked 8 bit parallel bus design.) When HD goes low, You know that the current scan line is done. Once HD comes back high, you’re clocking data out for the next scan line. After all the scan lines have been sent the camera will take HD and VD low, and hold them there until it’s ready to clock out more data.
Setting the camera up is done using the I2C bus connections. Sending the camera’s address (it’s in the data sheet) along with the register you want to change settings in, and the value for the register, will change the setting. According to the report from the Army, the only command you need to send to the camera is 0x02.
NOTE: The camera is NOT a 5v or 3.3v device. It might work with those voltages (I wouldn’t try it) but most likely it’ll release the magic blue smoke and crap out on you. Logic High will be the same as the camera’s voltage source (it’s in the datasheet.) Logic low is ground, or 0v. ALL the IO pins on the camera are digital IO.
What do you need to provide the camera?
-Voltage (VDD) and Ground (VSS)
-Dclk - A square wave with a frequency >= 6mHz
-I2C interface - You’ll need to tell the camera to start taking frames.
-2 digital inputs for the camera’s control lines. You NEED to make these interrupts, because the camera will start sending data whether you’re ready or not.
-8 digital inputs – This is your parallel input bus.
Keep in mind that you have .16 microseconds (assuming Dclk of 6mHz) to read the byte, process the byte and get ready for the next byte. With the Arduino running at 16 mHz, that gives you approximately 2 processor clock cycles to play with. 2 clock cycles isn’t much to play with. You may have time to execute 1 ASM instruction. Even with a processor running at 20 mhz, you’ve only got 3 cycles. A Dclk of 6mHz also only gives you ~ 9 frames per second. Great for still shots, but if you want full motion video, you’d need about 15-18 mHz at Dclk.
In short the Arduino has nowhere near the processing speed to handle directly interfacing this camera.
If you really want your arduino to interface with this camera, you need something in between, that can buffer an entire frame’s worth of data from the camera and spit it back out slowly to your arduino. You could use an ARM7 or ARM9, or program an FPGA to do the job. The clock for a DSP would need to be approximately 50-100mHz to make it able to handle the task.
@thebecwar u gave the best response so far thank you very much. Now I have all the info I need!
Btw I will be using still frames for tiny image processing(comparing pixels between them) aprox 1fps. I think arduino will make it what do you think?
If you drop the camera’s Dclk rate to 1 MHz, and code directly in ASM, you might be able to do it. I say might, because we aren’t talking about a lot of head room here. Plus the amount of data being slung about is pretty significant. Even a 640x480 image will take up about 600k of RAM. (640x480 = 307,200 pixels * 2 bytes per pixel = 614,400 Bytes = 600kB) If you’re comparing 2 images, that’s 1200kB of raw data.
I think you’ll run into the biggest hurdle trying to time out the interface.
Input/interrupt processing on the AVR takes (at a minimum):
4 clock cycles to enter the interrupt vector
2 clock cycles to store the register value (assuming you’re using all 8 pins from only 1 IO Port) and post increment the pointer.
2-6 clock cycles to test the pointer, figure out if you’ve gotten 600k and jump if you need more data
(This assumes you aren’t returning from the interrupt. Add 4 clock cycles for each pixel if you are.)
Each clock cycle @ 16MHz is 0.0625 microseconds (us). If you’re running the camera at 1 mHz, the Dclk will cycle low->high every microsecond. At 1mHz the camera image will be over exposed and washed out at best. This is the best case scenario. Anything over .5 us, and you’ll miss the falling edge of the clock pulse and miss your chance to read in the data. If you code very carefully you might be able to get away with 1 us per pixel, but I can’t say for sure. The best case scenario has it at 8 cycles to process a pixel, with the worst case being 12. 8 clock cycles is 0.5 us, and 12 is 0.75 us.
There’s little to no room for mistakes. Keep in mind also, that you need to generate the square wave clock pulse. You could do that in your assembly code, if you’re VERY careful, but it’s tricky at best. Triggering an interrupt on the falling edge of the clock might work, but that adds complexity, depends on an external clock source, and adds at least 4 cycles to your loop.
In theory it can be done. The timing requirements are what’ll most likely end up making or breaking the project. The 8bit AVRs are great MCUs but they are not really up to the task of processing data coming in at 8 Mbps. (Yes that little camera is really shoveling 8 million bits per second @ 1MHz.)
I’m not saying it’s impossible, but it’s like building a rocket powered Honda. You might get from point A to B, but in between, you’ll probably want to pray.
I get what you mean, and no, I will be processing the same image, I won’t be outputing video. Imagine it like that. I capture a picture, when the first pixel comes I save the RGB colors in 3 variables, each pixels arrives next I compare its RGB colors with the current pixel, if it is lets say… more green I replace it and so on for the rest of the pixels. I will also be using a counter to identify the pixel coordinates. That will take me about 5 ram places and I guess comparing won’t be that memory consuming.
Whats the worst case scenario? Is there any possibility that my camera and/or arduino processor will be baked? (Assume I have done the logic level conversation successfully. )