[Top][All Lists]

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

Re: [Discuss-gnuradio] atsc_cpll finally works

From: Brian Padalino
Subject: Re: [Discuss-gnuradio] atsc_cpll finally works
Date: Wed, 21 May 2008 11:25:33 -0400

On Wed, May 21, 2008 at 7:12 AM, Charles Swiger <address@hidden> wrote:
> We get a complex datastream from the usrp with signals from -3.2 to
> +3.2Mhz (6.4Mhz wide, easy /10 decimation - Eric wants 8Mhz ;).
> Previously we had to upconvert the spectrum to 5.75Mhz so that it's all
> positive frequencies, then we take just the real part
> (gr.complex_to_float) and then let the atsc_fpll lock onto the carrier
> and shift it down to 0Hz and then the 8vsb demodulation magic starts
> like you expected.     But why upconvert, then down-mix again? Why not
> just make a pll that would lock onto the carrier when it's somewhere
> around -3 + .31 Mhz and elimate one whole mixer?  That's what atsc_cpll
> (complex in, real out) is for.

I didn't realize the USRP couldn't do a real-only signal stream.  I
see what you're doing now.

> Now my question: Is it possible to tune the usrp so the carrier is at
> +.31 Mhz ? (band center at 3, from -.2 to 6.2Mhz?)  Then we could run
> the cpll at 6.4 or 8Msps and get another big performance boost, maybe.
> Right now the pll at 19.2 Mhz (6.4 * 3) is an expensive part. Eric, I
> guess the bit timing loop would work at 24Mhz (8 * 3).

Wouldn't it all work better if it was just done in the FPGA, and the
host was responsible for significantly less?  Your PLL could also work
at the full 64Msps sample rate if it were inside the FPGA.

To make space in the FPGA, you can fix the decimation rate at the
input of the CIC to be 8 which saves the muxing logic on the output
and eliminates a whole slew of registers and logic.

You can also eliminate the halfband filter and go straight to the RRC
filter to offload a good portion of the processing from the host.

Since a single ATSC channel takes up all the available bandwidth of
the USB connection, you can also reduce the number of channels from 4
or even 2 downto the single 1, and keep it real-only.  I can easily
see this fitting within that FPGA.


reply via email to

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