capturing video input (lowres/lowfps)

Go To Last Post
26 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I want to grab a picture from video input, and these are project demands:

video input: PAL or NTSC video composite signal (both are not a must)
speed: 1 fps
resolution: 32x32 minimum (64x64 or 80x60 prefered but not a must)
color: 256 grays (color prefered but not a must)
parts: no obsolete parts
cpu: AVR 8-bit (ARM with just GCC or even Linux is also OK)

I am looking for either cheap or easy way to do it, and I hope that you can help me with some ideas. Links to commercial solutions or chips that could help are most welcome. Googling didn't help much, and browsing existing topics on this forum helped only a little.

Yes, I browsed most of 277 topics listed when searching for camera, and I am aware of AVRcam, CMUcam, gbCAM and EyeCAM, but they are not what I am looking for. They might be interesting only if someone has an idea how could they be hacked to receive PAL or NTSC video signal instead of signal from embedded camera.

Easy solution will be some small micro-itx motherboard with PCI framegrabber card and linux, but I am looking for something smaller and less power hungry.

People mentioned LM1881, TVP5145/5150, EL4583, AT76C120 and other chips that could help in some other projects, but I wonder what would be the best solution for my specific low demands? Maybe CPU should do all the work? To be even more specific, CPU will have no other tasks but to send picture after capturing just once per second (over i2c, spi, port... I don't care).

Here are some links:
https://www.avrfreaks.net/index.p...
http://www.atmel.com/dyn/resourc...
https://www.avrfreaks.net/index.p...
http://www2.ece.jhu.edu/faculty/...
https://www.avrfreaks.net/index.p...
https://www.avrfreaks.net/index.p...
https://www.avrfreaks.net/index.p...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

80x60x256grey = 4800 byte RAM buffer for a frame.

Looks like you'll need one of the "big" AVRs or one with an external RAM interface unless you want to buffer the data serially to an external memory device over SPI/I2C

Once you have your 4,800 bytes each second what are you planning to do with it? (storage to flash memory card, compression?)

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With AVR 32x32 is enough for me, so this is not a problem.

I will generate short sound based on this data, and I think AVR is capable of all of this. If not, another AVR will receive data and generate sound.

That's all for now. Maybe, just maybe later will be added some image analisys option that will change sound.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Create sound from video? - intriguing. Do you mean doing some sort of FFT processing or something on the video and then making a sound based on the picture "content" or something? Remember that 8/16MHz processors are not really up to if there's any amount of heavy mathematics involved. In that case either consider a DSP or an ARM at a decent clock rate (100MHz+ perhaps?)

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Atmel are now looking to release their ARM derivative video micros to the general audiance rather than limited to the Big boys.

Keep it simple it will not bite as hard

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

64 pixel lines is "only" a 1 MHz or so dot rate, IIRC. Maybe all you need for monochrome is an A/D converter? For standard video, you only need 1 V P-P. Sync pulses are big, fat, and blacker than black, they should be easy to find. Doing color this way would be a bit of a hassle, for color you would probably want a video convert chip.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey,

See www.newae.com for the LoonBoard, which would do full colour / resolution video capture.

However, since you don't need that there is an easier way. Use an LM1881 (see http://www.national.com/pf/LM/LM...) to get the sync information. This can be used to get info on when the line begins.

From there you can use a 8-bit fast ADC to get information on the video. For just greyscale, you can effectively just read the value of the analog video.

Regards,

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you need to capture one frame, or are you willing to tolerate artifacts from capturing part of each of 30 frames? 4800 bytes can easily be captured by AVR over a second, it's just a matter of cleverly timing the ADC so it catches another spot when it can, and puts it into your output array.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@clawson
No heavy mathematics involved. Simple average of all pixels is enough to create a meaningfull sound for my application. Therefore, if I can grab single 32x32x256 frame with AVR there will be plenty of time for generating sound before next grab.

@dbc
I think that using some video chip to extract needed signals would make work a lot easier.

@c_oflynn
Thanks for the link! That's exactly what I was googling for without luck. Your post even helped me to find more links with same topic.
www.newae.com/loonboard/loonboar... - very powerfull but too pricy (300$)www.digitalcreationlabs.com/uCFG... - this might be adequate, I will examine details (150$)
www.iosoft.co.uk/fgrab.php - too bad this became commercial project (???$)
LM1881 and TVP5145/5150 seem interesting. Does any example code exist? If I understood well, I could wait for vsync interrupt, then wait for hsync interrupts and sample data (with logic to skip surplus and get only 32x32), and make sound or send data to other cpu. Is this correct? Can AVR make 32 samples per line with plain C (with timer interrupt)?

@mneary
As you can see, I need to capture single frame, then make sound during 24 (or 29) frames, then repeat everything.

Now that commercial solutions are found, does anyone know some open source open hardware frame grabber with microcontroller interface? I doubt but I have to ask, just in case :roll: :lol: .

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
LM1881 and TVP5145/5150 seem interesting.

The TVP5145 or similar would be the easy way to go! As long as you can set the devices up to output "Y" data on a seperate channel you are set. The Y data is also known as luminence, which alone gives you black-and-white images.

The TVP5145 can do this, the TVP5150 outputs both luminence and chroma (colour) information on one databus. If it just has one databus you have to figure out which data you are reading, which would require some more strict timing.

Lots of other people make these sort of chips too, Analog Devices and Phillips Semiconductor are two that come to mind.

Just use an external latch to read in the luminence data, as it will be clocked at 13 MHz roughly. An external latch with a enable driven by the AVR and the clock by the data clk output of the decoder provides an easy way to make sure the data won't change as you read it.

Quote:
Now that commercial solutions are found, does anyone know some open source open hardware frame grabber with microcontroller interface?

NewAE provides a schematic for the LoonBoard. It's not exactly open-source, but it gives you some ideas.

Regards,

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think you should use saa7113 or saa7114 to decode video composite signal and use FPGA or CPLD to capture video frames. If you need further information to make this project. You can ask me.
Skype: vohienarm
YM: hienavr@yahoo.com
email:vohien06@vnn.vn

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is an old trick from the days when all home computers were 8 bit...
All you need is an ADC with a reasonably fast sample/hold circuit - the onboard adc might do it (if its sample time is too wide, a simple external S/H with an analogue switch or fet and capacitor would do the trick).
You take one sample per video line (or every 8th or so for your required resolution), and delay the sample point by one (or in your case maybe 8 or 16) pixels in each successive frame, building up a full image over a number of frames. This could easily be done with a sync interrupt (maybe could use the comparator instead of a LM1881) and a timer.
The only snag is that it isn't good for moving images as the content changes from frame to frame.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
building up a full image over a number of frames
Already proposed Aug 31; OP replied he didn't want to do this.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
@dbc
I think that using some video chip to extract needed signals would make work a lot easier.

If you are talking about chroma, yes, I agree you want a chip. But don't be afraid of sync pusles. If you buy into using an A/D for low dot-rate monochrome, the sync pulses are going to look like big, fat slow-pitch softballs compared to the fastball rate that the pixels are coming. Black is 80% modulation, sync is 100%, so there is lots of margin in sync detection. Heck, 50 years ago it was done with simple filters and vacuum tubes. A lot of good work went into making sync trivial to extract. If it was me, I'd go for a 1.5 Mhz A/D, front end it with a gentle analog filter that starts rolling off at 1 mHz, and do the rest in s/w. This will get you about 64 pixels per line and a 1 MHz dot rate. For your application aliasing is maybe not such a big deal, but if you care you could consider sampling at 1.5 MHz (assuming 1 MHz AFE cut-off) and do a 3:2 pulldown before further processing if there is sufficient CPU to do it all.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i am also interested in a similar application.
we are designing a small serial video interface box. basic specs:
* 640x480, 320x240, colour
* composite video input
* agressive jpeg compression (8 - 20kb images)
* 1 frame / 10 seconds is adequate
* rs485 output
* low power

we have yet to work out how we are going to build it, but since our engineering staff are very stretched at the moment we're looking to outsource.

our _preliminary_ thoughts are:
* analog devices ADV7180
* CPLD for JPEG
* atmega16 for IO

if this is within anyone's capability and interest, please let me know.

thanks,
simon

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

Perhaps the LoonBoard would do the trick - it has very similar features you requested... video decoder, FPGA, and AVR. It adds some more features even though...

This would just be physical hardware, are you talking about outsourcing everything?

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the loon board looks like a pretty good basis to build out our required functionality.

we'd need very very tight compression; e.g. jpeg or jpeg2000 -- but we have no experience with FPGA development. i'll write to you offline about NewAE's services.

-s

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just received LM1881 and I will start with it. Thanks to all who helped me with suggestions.

Next on my list is fast AD converter. Could anyone recommend one fast enough, not expensive, and easy to interface?

I am also concidering fast FIFO approach. To buffer whole frame with all data and then slowly decode info that I need from it. Could anyone recommend some FIFO that I could use for this purpose?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The only external ADC that I have access to and that fits project is TDA8708A (32MHz ;-)). Datasheet can be found at http://www.thought.net/jason/dev/rtvc/TDA8708A_5.pdf. I am quite new in this area and a little confused, and I need help with interfacing to ADC pins.

1. Application diagram (Fig. 12 at page 16 of this datasheet) says that besides other stuff I need to connect "horizontal sync", "horizontal clamp", and "low pass filter". Are all of these really needed?
2. I can get HSYNC from LM1881 which I already have, but I don't know what is "horizontal clamp" and how to get it.
3. Do I really have to implement low pass filter (Fig. 15 at page 18 ) or ADC can work without it?

I just want it to work with VIDEO IN signal from camera (CVBS), and I don't have high accuracy demand.

Any help is most welcome :lol: :P :lol:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

See the app-note for that device at http://www.nxp.com/acrobat_downl...

The filter is for anti-aliasing, and also "clock rejection". Perhaps in the analog part of the chip they had a fair amount of digital noise leak onto the data...

For that reason i'd try to put even the cheap filter they recommend on.

The app-note should give you hints on the rest of your questions... my internet is going really slow though so I can't get the whole document to check for sure!

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you are feeding it from a camera, this neat serial cam module might be of interest :
http://www.electronics123.com/s....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A simple fast A/D converter with just the right dynamic range ( TV screen / human eye are a combination which needs no more than about 47 dB dynamic range for PAL and less i suspect for NTSC ) could be a delta modulator.

http://www.its.bldrdoc.gov/fs-1037/dir-011/_1553.htm

a fast interrupt service routine might allow you to capture the edge transitions directly in terms of a timer counter content for later processing

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,
probably my visionAVR module (see http://www.chip45.com/visionAVR ) could be interesting for some people here? I'm currently testing the first prototypes, so series modules should be available in few weeks. It can capture a standard PAL/NTSC video signal and puts it into a 32k SRAM, i.e. 144x108 pixel color image or one 192x144 b/w image or two 144x108 b/w images etc. Resolution is fully programmable. Onboard CPLD for capture control and an ATmega128 for image processing in the linear video SRAM.
Cheers, ER!K

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@c_oflynn:
So much thanks for the link! There are still few things unclear to me, but today I have found schematics of a circuit where TDA8708A and LM1881 are used together (http://www-public.tu-bs.de:8080/~y0001729/doc/FGrabDoc.html). However, I still don't understand exactly where 74HC04 pins 2 and 4 are connected (lower in schematics, IC12A and IC12B). Should they stay that way? They do seam important since it's related to GATEB. Could anyone help me, please?

@Mikeharrison:
Very nice camera. I might use it sometime, but for this application I need to grab video input from any source so embedded camera is not an option.

@eriklins:
Nice module, but I can not say more until I see price and licencing terms. Will it be open source and open hardware? I do not plan to do this in C, and I wonder if interface is well documented so I can use it easily from some other programming language? Good thing (from my point of view) is that this module and audio out is all that I need, but bad thing is that it has some specific parts that will be hard to find in few years. I will definitelly consider when you release it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

For the GATEA/ GATEB stuff, see page 23-25 (PDF page numbers, not page numbers on document). They describe the operation of those pins.

They are used in the automatic gain control of the signals. The GATEA signal is supposed to be high during sync, and GATEB is high during black level.

Anyway the pins 2 and 4 are left unconnected. On CMOS logic if you leave inputs floating, they tend to draw excessive amounts of power. So you force the input on unused gates to a known level (low or high) and leave the output unconnected.

They just happen to put the gates near GATEA and GATEB, they don't actually do anything...

Regards,

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

may be you can use the software from aneesoft.