Hi, Finally, I got my first HDTV screenshot tonight. It's from KTVU's "The Loop". Here's how I did it: 1) Download ATSC stream off USRP with the following parameters: TVRX's rf freq = 725e6 USRP's center freq = 43.75e6 Decim = 8 TVRX's Gain = 88; USRP's format = 0x300 Mux = 0xf0f0f0f0 See ktvu-complex.png for the FFT pic 2) Upsample 8Ms/s complex data to 40Ms/s complex data: for every sample in the 8Ms/s data, add 4 zeros, then followed by a lowpass filter. 3) Downsample 40Ms complex data to 20Ms/s complex data: remove every other sample from the 40Ms/s sample data 4) Frequency Translate the center frequency from 0Hz to 5.75MHz 5) Keep the In-phase part of the 20Ms/s complex data to get 20Ms/s real data: See ktvu-real.png for the FFT pic 6) Feed the 20Ms/s real data into Gnuradio 0.9's atsc_rx. Voila! The finally screenshot is here: ktvu-The Loop.jpg Cheers! Mao
on 2006-04-03 08:54
on 2006-04-03 09:24
On Sun, Apr 02, 2006 at 09:45:26PM -0700, mao mao wrote: > TVRX's Gain = 88; > USRP's format = 0x300 > Mux = 0xf0f0f0f0 > > See ktvu-complex.png for the FFT pic Great job! Glad to see that those bits are still working ;) Now that you know it's possible with the USRP, can you help out with porting it to 2.x? Maybe you can set up your machine to dual boot GNU/Linux? BTW, the process you described is about 4 lines of python code in 2.x ;) Thanks, Eric
on 2006-04-04 04:43
On Sun, 2006-04-02 at 21:45 -0700, mao mao wrote: > Hi, > Finally, I got my first HDTV screenshot tonight. It's > from KTVU's "The Loop". > > Here's how I did it: > 6) Feed the 20Ms/s real data into Gnuradio 0.9's > atsc_rx. > Veery inspiring - here's my nearby station on 41 (632-638M), about 10 miles away, holding a scanner antenna indoors: http://webpages.charter.net/cswiger/photos/wchs-41.jpg The conversion makes sense - however I cannot get gnuradio-0.9/atsc_rx to compile (yet). --Chuck
on 2006-04-04 05:05
On Mon, Apr 03, 2006 at 08:40:55PM -0400, Charles S. wrote: > > Veery inspiring - here's my nearby station on 41 (632-638M), about > 10 miles away, holding a scanner antenna indoors: > > http://webpages.charter.net/cswiger/photos/wchs-41.jpg Looks like a nice clean signal. > The conversion makes sense - however I cannot get gnuradio-0.9/atsc_rx > to compile (yet). <soapbox-mode> You know, I wish you guys would quit screwing around with the 0.9 code, and instead help us *all* move forward by investing some time in porting it to 2.x. The framework is already set up, and the first 4 blocks have been ported and tested. I'd really like some people to step up and finish it off. It's in CVS under gr-atsc. We've also got *much* faster filtering algorithms in 2.x. We might even be able to get it running in real time on a dual processor machine. Today's machines are a lot faster than when we first wrote it. </soapbox-mode> Let me know if you've got any questions. Eric
on 2006-04-04 05:14
Eric B. wrote: > machine. Today's machines are a lot faster than when we first wrote it. > > </soapbox-mode> > > Roughly every 18 months, available CPU speed doubles. Which means that using todays machines, if you can just-barely-not-quite do real time now, in 18 months you'll be able to, on a machine that costs you roughly what your current machine cost you. Single-CPU Moores law *is* slowing down some, but multi-core appears to be making great strides. My astronomy apps are pigs. But I can do useful stuff with them. On my single-processor 2.6Ghz Celeron D, I can manage 2Mhz of combined total-power and spectral observations. On Lamars Dual-CPU Xeon, he's able to do 8Mhz using the same code. My pulsar application can run at roughly 1Mhz bandwidth on my single-CPU 2.6Ghz Celeron D, and we haven't tested it on Lamars Dual Xeon system yet. When the de-dispersion filters get longer, that 1Mhz will be pushing it on a single-CPU system. I'm having a hard time believing that processing ATSC video is a *less* CPU-intensive application than pulsar processing, but I could be completely wrong.
on 2006-04-04 06:06
Amen: There are many of us who can help push this across the finish line and think this is a neat application but it might as well be closed source in its current state. Bob Eric B. wrote: > first 4 blocks have been ported and tested. I'd really like some > > > -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman Laziness is the number one inspiration for ingenuity. Guilty as charged!
on 2006-04-04 06:34
On Mon, Apr 03, 2006 at 09:11:37PM -0400, Marcus L. wrote: > > I'm having a hard time believing that processing ATSC video is a > *less* CPU-intensive application than pulsar processing, but I could > be completely wrong. > We'll see ;) We know more now then we knew then (good thing!) We can use fft based filtering, which should speed up a lot of the code. In addition, if we stick to training the equalizer only on the VSB data field sync, we can use fft filtering in the equalizer for 311 out of 312 data segments in every field. The equalizer is currently running 256 taps at 10.76 MS/sec. Moving from N^2 to N log N should help. Eric