Re: [Discuss-gnuradio] signals/atsc question

[Eric Blossom]

On Tue, Mar 01, 2005 at 10:14:17PM -0800, John Gilmore wrote:
> > (and while I do have access to an mc4020 board, it is
> > not in a location that can receive ATSC signals and I'm not about to run
> > coax all over the place).
> 
> I have to start by saying: either moving the mc4020 board to where the
> antenna is, or running coax all over the place, will be MUCH easier
> than to do what's needed to squirt this fat a signal over the USB bus.
> The mc4020 board runs fine in the current GNU Radio 2.x infrastructure.
> 
> (Maybe Matt or Eric, or someone else on the list, has some better
> ideas than what I discuss below.  I'm not a signal processing guru,
> and they are.)


> > I am using a 4937 frontend, so that gets the
> > USRP a signal from 2.75 to 8.75MHz. The only way that I've been able to
> > capture the signal reliably is by doing a DDC by -5.75MHz with a
> > decimation factor of 8. This puts the signal nicely between -3 and +3
> > MHz, at 8MS/s with complex samples. In order to convert this to 20MS/s
> > real, I've tried two approaches:

That's the appropriate setup for the USRP.  

20MS/sec isn't magic, it's just what the mc4020 would do.  At 10MS/sec
we would have had Nyquist problems, hence we used 20M, the next rate up.

> There are about 10.76 Msymbols/sec in an ATSC signal, so you are going
> to have Nyquist problems if you try to represent them in 8M complex
> samples/sec.  You'll need at least 10.76 complex MS/s.  (Indeed you
> may notice that we were skating inside the edge by using 20
> non-complex MS/s on the old hardware.)

Recall that Nyquist doesn't say anything about the number of symbols.
The thing you have to worry about is the bandwidth of the signal.  The
TV channel is only 6 MHz wide, therefore 8 MS/sec complex will capture
all of the information and will fit across the USB without a problem.
The USRP will work fine.

> I'm a little surprised that the code in the USRP's FPGA doesn't do
> arbitrary sample rate conversion, which would let us just say
> "Whatever the hardware sample rate is, don't worry about it --
> interpolate those samples to 20,000,000 samples per second and hand
> them to me over the USB".

"Left as an exercise for the student"

Altera has a nice app note on synthesizing multipliers by burning up
RAM.  As I recall it's not too hard to generate a multiplier that does
12-bit*16-bit in two cycles.  We're clocked at 64 MHz, though 128 MHz
should be possible with some hacking.

If you're decimated down to 8MS/s complex and want to use an 8-tap FIR
interpolation filter you need to peform 8M * 2 * 8 = 128M multiplies
per second.  This should be possible using a pair of RAM based
multipliers.  I don't recall how much RAM it takes.  It's non-trivial.

There's a good discussion of interpolator design and optimization in
chapter 9 of "Digital Communication Receivers: Synchronization,
Channel Estimation and Signal Processing" (ISBN 0-471-50275-8).
It's not for the faint of heart ;-)

Anybody looking for an interesting and useful challenge is invited to
code this up.


> > Both of these methods yield similar results -- the gnuradio-0.9 atsc_rx
> > happily takes the input, and generates an output TS file, with an error
> > rate of 1. However, I have plugged this very same antenna pointed in the
> > same way into my pcHDTV 3000 card, and it has no problems with the
> > signal (maybe an occasional glitch).

See John's comments on antenna pointing.  Also, the pcHDTV 3000 most
likely implements a better equalizer than we did.  Improved algorithms
are welcome.  Last time I checked there was a pretty good body of
literature on ATSC equalizer design.  It took until the 3rd generation
ASICs until they had any chance of working with indoor antennas...


Meanwhile, back to using the USRP for ATSC demod:

The data will fit across the USB.  

Note that there's no reason you couldn't run the bandpass root raised
cosine filter and the pilot tracking loop at 8 MS/sec complex.  The
code would be slightly different since it's complex instead of real,
but no big deal.

Then just prior to GrAtscBitTimingLoop3, interpolate the complex
signal by 3 to 24MS/sec and toss the imaginary component away.  
I suggest 24MS/sec and not 16MS/sec because the MMSE fractional
interpolator used in GrAtscBitTimingLoop3 requires the input rate be
at least 1.8 x 10.76M (19.4M).  This constraint arises from the design
of the filters in the MMSE interpolator.


I don't have my ATSC notes at hand.  I have seen them in the last
month or two so they shouldn't be too hard to find.  When I find them
I'll scan them in and post them to the wiki.

> Note that your disk will need to be able to keep up with your sample
> rate.  At 20 Msamples x 2 bytes/sample we used Linux's "LVM" (logical
> volume manager) support to stripe a pair of partitions (on different
> IDE buses) to handle writing at 40 Mbytes/sec.  If you can't do that,
> you'll need to buffer it all in RAM and write it out at the end.  RAM is
> cheap, and a gigabyte will store 25 seconds of samples.

This worked fine for us.  You will need to solve this problem,
otherwise you'll never be able to record contiguous data for later
demod.  The other key was to use the ext2 filesystem, not ext3
(posting the journal was killing us).  You may also want try the XFS
filesystem.  I suggest two fast cheap drives.  We used two Western
Digital 120 GB drives.  Today I'd probably go for the 200+ GB ones.
If you can find real benchmarks, the key metric is sequential write
throughput.

> Also note that our southbridge had a bug in which pushing a lot of
> disk traffic would starve the PCI bus for cycles, disrupting the
> signal capture's DMA.  We ended up moving the disks onto a PCI IDE
> disk controller, rather than using the motherboard IDE controller.  YMMV.

FWIW, we used a Promise Ultra133 Tx(something?) -- 64-bit/66 MHz IDE controller.

Eric