Re: [Discuss-gnuradio] Re: usrp_tv_rcv issues

[Martin Dvh]

Nathanael Nerode wrote:
> Matteo Campanella wrote:
> 
> 
>>Hello folks, here there is an interesting piece about the nice usrp_tx_rcv
>>and the status of the art as of now.
>>I am sending it to the list with the consensus of Martin.
> 
> <snip>
> 
>>>A needed add-on is also color-decoding, color-video-sink and
>>>audio-decoding.
>>>Audio-decoding should be straight-forward because it is just a variation
>>>on FM-radio (for PAL-TV)
>>>The problem is that you need the full 6Mhz bandwidth to get the color and
>>>audio sub-carriers and for most PC-s this is too much for realtime
>>>decoding.
> 
> Is it perhaps possible to implement some of the decoding in the USRP, so as
> not to clog the PC's CPU?  Perhaps a specialized daughterboard?
Although possible, it is not the first thing to persue.
(premature optimization)
Lets first get it to work in software non-realtime.
Then optimize the software
        optimize algorithms, parameters
        convert to a single block, remove unneeded copying
        use simd (mmx, sse, 3dnow) optimizations
Optionally convert to gpgpu code (I have done this before, this can give you 
big wins)
Or do processing in the fpga.

> 
> 
>>>A quick-and-dirty solution could be to use a second channel in the usrp
>>>tuned to the audio-carrier with smaller bandwidth.
>>>(For color this will not work because you need exact
>>>phase-relationships.)
> 
> Hmm.  I'm not sure I see this.  If the luminance channel and the color
> channel are being digitized through different channels but with extremely
> exact timing, can't the phase be kept synchronized for at least a full
> line?  The synchronization code should make sure that they're resynced at
> the beginning of each line.  Or is there simply not enough exactness in the
> timing.
> 
You use the second channel with a different frequency, so you introduce a 
(known, but not exact) phase difference.

Since you use two channels from the same usrp, the time relation between the 
two channels should be exact (pixel-accurate).
You only need to account for the phase/frequency difference.

Since you have the color burst at the start of every line, it might be very 
well possible to get this to work.

Greetings,
Martin