I have searched everywhere for this device, but have only found extremely expensive and large units.
Basically I am looking to send a vga signal to the arduino analogue inputs, use the sync signal to write the vga data into an array on the Arduino.
I have done a lot of reading, and from what I have gleaned it should be possible. Take a DVI cable and use Pin 8 and C 4 to sync up, and then the sampling rate of the analogue ins defines the possible resolution per frame.
Sample rate of the analogue ins is roughly 100us, divide by 30 frames/second and I should, theoretically, be able to see 333 pixels at full speed coming over vga. Combine that with something intelligent like a change-reporting method over USB to perhaps even extend that further.
I was wondering, what are the potential bottlenecks I should be concerned with? Will it be possible to pass on the data, say a 16x24 matrix of pwm'ed RGB values at the same rate? Roughly 30hz?
Just going through the motions here, trying to focus in on where I need to do most of my studying.
Thanks,
Andreas.
Arduinos almost seem like magic, but they aren't. This won't work for many reasons. Overall speed... A/D speed...you can't sample all channels of the A/D at the same time...and I may be wrong, but I believe there is just 1 A/D and a multiplexer to each of the inputs. Being able to read 1 channel at x Hz does not mean that you can read all channels in parallel at x Hz.
Just because the update rate may be 30fps, you don't have the whole 1/30 of a second. You have H&V blanking times included in that which must be subtracted. And who runs their output that slow anyway. Good, non--flicker scan rates go way above that. I'm at 75 right now. (Don't know if it is interlaced.)
To do just low res 640x480 even as slow as 30fps, you'll need ~ >10Msps on each channel (RGB) and trigger the A/D function on all 3 colors in simultaneously. There is a reason frame grabbers cost $.
There maybe ways that you can do this with an arduino. This is an idea that might work ...
if you are happy with 16x16 digitising, you could do the digitising on separate frames. It is tricky to put into words, but if you imagine the screen in a 16 x 16 grid labeled 1 thru' 16 across the top and A thru' P down the side. You would have some timing facility to be able to digitise the signal in the centre of each of the 16x16 squares.
One the first screen you would digitise A1, B1, C1 etc. On the next frame you would do A2, B2, C2 etc. You would be able to do the whole screen in 16 frames, but movement may be blurred.
If timing is tricky to do one column per frame you could do less, maybe half a column or at least one cell per frame, though the update time may then be unsuitable.
Also, if you are outputing to a single colour LED, you could combine the RGB signals with some op-amps and then you will only need to do one conversion per cell.
I hope I understood your application and that this help a little.
I did something similar back in 1987 although this was to input a video signal into a microcomputer. The text & description is on the net http://www.doc.mmu.ac.uk/STAFF/A.Wiseman/Acorn/BodyBuild/BB_87/BBC49.txt but sadly no schematics.
It took just over 3 seconds to get a 128 X 128 black and white image into the computer.
This sort of thing (called a frame grabber) was used by Radio Hams to get pictures to transmit using what was known as "Slow Scan TV" (or SSTV). You might try looking around for those sort of links.
While a TV camera is not a VGA output it is quite close to it and any frame grabber circuit could be easly modified.
