[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] working example gnuradio TV receiver for NTSC and

From: Martin Dvh
Subject: Re: [Discuss-gnuradio] working example gnuradio TV receiver for NTSC and PAL (black and white)
Date: Fri, 07 Jan 2005 19:21:02 +0100
User-agent: Mozilla Thunderbird 0.9 (X11/20041124)

 I am thinking that we can collect some data that approximately
corresponds to atleast one frame, then parse it to note the position
of H and V sync pulses and then with this information parse it again
to build a frame. That way even if as you told, the lines are not
constant length, we should be able to decode, with the pixels for the
remaining missing info put to something like black ....
Sounds good.
You could even take enough samples to have several frames.
Then do an autocorrelation to determine the exact number of samples in one 
Using this information average several frames.
Now you have a very high quality frame (less noise)
From here we can determine the sync level (lowest value) black level (blanking interval,preceeding and following sync) and white level (maximum value)
Then we can determine the position of the sync pulses and the sync length in 
this averaged frame.

Now we can use the found sync and black level and expected sync positions to 
get the sync position in the normal signal.
It is possible to do a cross-correlation between the normal signal and the averaged signal to find the sync position. This would however be quite computational intensive.

Less computational intensive would be:
We now the expected length of the sync pulse.
If the average of the current sample and a few succesors are below black level and the average of the samples sync_length in the past and a few succesors are below sync level then current sample is at the end of the sync pulse.
(In stead of average we could also use a majority function (80 % of the samples 
are below black level))

I also found this old code, which was at some day part of gnuradio.

It is a software NTSC decoder which does seem to try to get the vertical sync 
I studied some time on it to try to grasp what they are doing with the sync, 
but is very hard to read code.

I think that they count the number of samples taken and as soon as a vertical 
sync pulse is due they start looking for it.
They even increase the number of filter taps at this precise moment to have 
temporary better signal quality.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]