discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] USRP Custom Filter Taps


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] USRP Custom Filter Taps
Date: Tue, 10 Oct 2006 20:36:31 -0700
User-agent: Mutt/1.5.9i

On Thu, Oct 05, 2006 at 05:51:49PM -0700, Daniel Garcia wrote:
> Matt Ettus wrote:
> >Yes, you can change the filter taps in the FPGA.  See the halfband (HB)
> > verilog code.
> 
> Thanks! I'll take a look.
> 
> >> I read on a previous thread that it is possible to invert the spectrum of 
> >> the sampled signal so that the tuned frequency would be the FM carrier. 
> >> The end result being a stream from the USRP where 0 Hz is the center 
> >> frequency of the audio carrier the the video carrier is at 4.5 MHz. Is 
> >> this possible? The advantage here is that the base-band audio does not 
> >> need to be shifted before FM demodulation; also the video carrier does not 
> >> need to be shifted before demodulation (AM). 

> >Not sure what you're looking for here.

> After thinking about it, I'm not sure either. I figured I can to
> tune to FM carrier to the center frequency (0Hz), set the decimation
> to 4 (16 MS) and the video carrier is at -4.5MHz. Unfortunately, my
> USB/computer can't handle can't handle the 16 MS rate. I was hoping
> to avoid translating the signal by placing the FM signal at
> 0Hz. Since my PC can't handle that data rate, I'm just going to
> concentrate on the NTSC.

> -Daniel
> 

> As an aside: It would be nice to have something like the GC4014
> on-board the USRP. In my application it could be used to tune the
> video and audio signals on separate receiver channels without using
> up resources on the PC (and also reduce the need for a faster
> interface in some cases). Not sure if there's enough room on the
> FPGA though.

The cost of extracting and decimating the audio portion of the full
signal in s/w is pretty small.

Have you tried just setting decimation to 8 giving 8MS/s complex?  Why
are you concerned about anything at 16MS/s?  The 8 MS/s signal will have
both the audio and video in it.  A small amount of filtering would
separate the two streams in software.

Eric




reply via email to

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