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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
