Analyze NTSC Signal - Possible?

[nrandal]

Is it possible using propeller to analyze an ntsc signal?

I want to look at frames as an extremely low detail grid and average the colors for each square. Say for simplicity and processing sake I could break the frame into a 2x2 grid.

If yes, can anyone point me in the right direction as to how?

I have been searching the forum and obex and I am not finding anything.

[potatohead]

http://forums.parallax.com/showthrea...-video-capture

[Phil Pilgrim (PhiPi)]

If, by "colors" you mean something other than grayscale, no, you will not be able to to this with the Propeller. But, if you're concerned only with brightness, something like what you propose should be possible.

The overlay program for the Propeller Backpack provides a way to lock onto the video's sync. From there, a sigma-delta ADC should be adequate to acquire average brightness levels from each line or part of a line.

-Phil

[Duane Degn]

There's also Hanno's method.

You'd have to use color filters over the black and white camera's lens to get color information.

I've used Hanno's method in this project.

Have you seen the discussion about the laser rangefinder?

It looks like you can get a color image from the camera it uses. A big problem is all the RAM a color image takes up. I plan to use some external SRAM to hold a captured image in order to analyze it.

Duane

[Dr_Acula]

I'd love to give this a try one day. Partly because I've never really understood how NTSC encodes color and I'd like to see the waveform for myself.

The bandwidth is (I think) around 6Mhz so you would need to sample ideally at least twice this speed. So you need a fast A to D. I've pondered taking a 512k ram chip and clocking it as fast as it can go (55ns). For the A to D, use 8 fast op amps with a resistor ladder so it samples like a bargraph with 8 values. That is the same resolution as the propeller outputs (3 bits). Clock in 512k samples into the ram chip. Then there will be plenty of time to go through and convert the bargraph into binary values, and find the start of the frame and the end of the frame, and then to try to work out the phase of the waveform to get the color.

[kwinn]

I'd love to give this a try one day. Partly because I've never really understood how NTSC encodes color and I'd like to see the waveform for myself.

The bandwidth is (I think) around 6Mhz so you would need to sample ideally at least twice this speed. So you need a fast A to D. I've pondered taking a 512k ram chip and clocking it as fast as it can go (55ns). For the A to D, use 8 fast op amps with a resistor ladder so it samples like a bargraph with 8 values. That is the same resolution as the propeller outputs (3 bits). Clock in 512k samples into the ram chip. Then there will be plenty of time to go through and convert the bargraph into binary values, and find the start of the frame and the end of the frame, and then to try to work out the phase of the waveform to get the color.

What you are describing is called a flash ADC. An 8 bit flash adc would have 256 comparators and logic to encode the output from the comparators into an 8 bit number. There were also some that lit leds for VU meters but I do not know if they were fast enough.

[Dr_Acula]

A flash A-D would be even better. Any suggestions for something 10-20Mhz?

[Bean]

Have you seen the discussion about the laser rangefinder?

It looks like you can get a color image from the camera it uses. A big problem is all the RAM a color image takes up. I plan to use some external SRAM to hold a captured image in order to analyze it.

Duane

The laser range finder as a camera would work great.
Right now we are working on 128x80 YUV422 color image. But lower resolutions would be easier, and could probably be sent as RGB to make processing easier.

Bean

[ericball]

I'd love to give this a try one day. Partly because I've never really understood how NTSC encodes color and I'd like to see the waveform for myself.

NTSC encodes two color difference signals (R-Y and B-Y) using quadrature amplitude modulation and a 3 579 545 Hz carrier. Two methods to recover the original waveforms:
1. Sample the data at 14 318 182 MHz (phase locked to the colorburst) then use sum and difference of sequential samples.
2. Use a filter to separate the luma and chroma then use a phase locked 3 579 545 Hz carrier to demodulate the chroma signals then low pass filter and sample each signal separately.
The advantage of #1 is you only need one ADC, but #2 can sample at a lower rate (with corresponding lower resolution).

[kwinn]

@ Dr_Acula

Take a look at this site (http://www.maxim-ic.com/app-notes/index.mvp/id/810) for some info from Maxim.

I have only used a flash adc once, and that was almost 20 years ago. It was power hungry, tricky to work with, and very sensitive to board layout. They have advanced considerably since then, but are still power hungry and difficult to work with.

There are quite a few 8 and 10 bit ADC's available in the 20 – 40MHz range at prices ranging from $3.29 to $30.00. Take a look at Digi-Key, Mouser, Newark, etc.. These are mostly parallel output units, but that is probably what you want for this application so you can write the data directly from the adc to the memory.

I have not used anything like this for several years so I am reluctant to recommend a particular chip.

[jmg]

Is it possible using propeller to analyze an ntsc signal?

I want to look at frames as an extremely low detail grid and average the colors for each square. Say for simplicity and processing sake I could break the frame into a 2x2 grid.

Depends what do you mean by low detail ?
Colur is Phase/Amplitude encoded, so for NTSC, a full 360' is 279.365ns, but the colur info can phase-jump at anytime (usually it will update on a Character time boundary, not on a chroma-time basis), and you need to measure phase relative to the signals own burst.

You can use an external demod, (which will already have the filters, and Crystal locking, and multiplying quadrature decoders built in) and then just measure the Analog Colour directly, or you can try and build your own demod, which gets complicated quickly.

http://www.intersil.com/data/an/an9765.pdf
http://www.analog.com/en/audiovideo-...cts/index.html

[Dr_Acula]

@ericball

Sample the data at 14 318 182 MHz (phase locked to the colorburst)

So if we could somehow phase lock the colorburst, then fire off the sampling so it samples in phase, would that improve things?

Could the propeller be used to generate the precise timing delay using a counter?

And could you detect the colorburst by waiting with some sort of fairly imprecise timing so you are roughly in the middle of the colorburst, then use a zero crossing detector to get the precise point of the zero.

But then again, #2 as you suggest would need a lower sampling rate.

I kind of know all the theory here because I have done PLLs etc but only at audio frequencies. Video frequencies are a different ballgame. What sort of sampling rate are we talking for option #2?

[Rayman]

My evil plan is to use an SSD1928 along with a video decoder to capture and process image and/or video and perhaps save as .jpg or .mpg.

May never happen, but that's the plan... On paper, I think it provides the best solution. But, there's lot of hard work to make that one happen...

[jmg]

Could the propeller be used to generate the precise timing delay using a counter?

Very Unlikely. Far too much noise and jitter.

You really want to use ALL cycles, (not just the Zero cross of one), and a gated phase compare, with good float behaviour, and then lock a real crystal - this is how TV decoders work, and this has the best Signal/Noise.

As a benchmark, if you want 0.5% Phase jitter in your baseline, you need to resolve and control to 1.396ns
A locked Crystal will do this.

[kwinn]

Probably cheaper and much simpler to digitize the rgb and synch signals from an older crt based TV set if you are interested in the image rather than the timing and phase information.

[Phil Pilgrim (PhiPi)]

One other little gotcha is that the color saturation is encoded as the amplitude of the chroma signal, which rides on the intensity signal. So you not only have to measure the average level to get the intensity, the chroma's phase to get the hue, but also its amplitude to tell how much of that hue to add to each pixel.

-Phil

[ericball]

One other little gotcha is that the color saturation is encoded as the amplitude of the chroma signal, which rides on the intensity signal. So you not only have to measure the average level to get the intensity, the chroma's phase to get the hue, but also its amplitude to tell how much of that hue to add to each pixel.

If you sample the two color difference signals separately then the phase isn't measured directly, just the amplitude of the two color difference signals (x,y versus phi,r). However, that does bring up the requirement for gain correction as you can't assume the signal is 1Vpp. Instead you measure the sync pulse and the colorburst amplitude and scale the luma and chroma based on those values.

[ericball]

So if we could somehow phase lock the colorburst, then fire off the sampling so it samples in phase, would that improve things?

Yep. Then you end up with Y+U, Y+V, Y-U, Y-V sequential samples and extracting Y, U, V is simple sum & difference followed by a simple low-pass decimation filter.

Could the propeller be used to generate the precise timing delay using a counter?

Maybe. I've certainly generated decent video using the Propeller's video generator PLL clocked at 14 318 812 Hz. The trick is getting the Prop to retrieve the samples at that rate.

And could you detect the colorburst by waiting with some sort of fairly imprecise timing so you are roughly in the middle of the colorburst, then use a zero crossing detector to get the precise point of the zero.

Dunno. The trick is still going to be getting the Propeller to save the samples from the external ADC at 14.318 MHz. Maybe have an external PLL which then feeds the Propeller's CLK input.

But then again, #2 as you suggest would need a lower sampling rate. I kind of know all the theory here because I have done PLLs etc but only at audio frequencies. Video frequencies are a different ballgame. What sort of sampling rate are we talking for option #2?

For #2 the PLL runs at 3.57MHz (or a multiple depending on the quadrature decoding circuit). The actual pixel sampling can be done at any frequency, but you're typically looking at 1-10MHz for each signal.

[Dr_Acula]

Based on experiments outputting video, by the time you toggle address pins and sample etc, you can only drive a ram chip about half the speed you need for video. So I suspect input is going to be the same, ie the data is not going to be able to go through the prop chip and then into a ram - it has to go directly into a ram, and then get processed later at a slower speed.

So if that is true, then what data could you sample into a ram, and at what speed? Raw data, or pre-filtered data? Synchronised to an external xtal, internal clock on the prop, or unsynchronised?

Colorburst xtals are cheap, as are simple filter circuits, so if pre-filtering makes things slower and hence more manageable then this could be an answer.

Things like the amplitude measurement as PhiPi points out, could be easy to do once you have 512 samples of something in a ram chip.

Do you do the pre-filtering and then sample into two ram chips?

Would a locked external xtal circuit be useful, rather than trying to do everything in the propeller?

[kwinn]

@Dr_Acula, data can go directly from one or more adc chips into ram chips at greater rates than NTSC video requires.

The data outputs from the adc chips go directly to the data input pins on the ram chips.
A high speed binary counter generates the memory address for each pixel in a single scan line (or an entire frame if desired).
The prop produces the signals to start an adc conversion, write the data to ram, increment the pixel counter, and the housekeeping for determining start of a scan line, start of a half frame, etc. This can be done with one cog and some external hardware or multiple cogs and no external hardware.