[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss-gnuradio] Re: usrp_tv_rcv issues
From: |
Nathanael Nerode |
Subject: |
[Discuss-gnuradio] Re: usrp_tv_rcv issues |
Date: |
Tue, 15 Aug 2006 03:18:21 -0400 |
User-agent: |
KNode/0.10.2 |
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?
>> 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.
--
Nathanael Nerode <address@hidden>
Bush admitted to violating FISA and said he was proud of it.
So why isn't he in prison yet?...
- [Discuss-gnuradio] Re: usrp_tv_rcv issues,
Nathanael Nerode <=