My First HDTV screenshot from USRP

GNU Radio
1

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

  1. 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.

  1. Downsample 40Ms complex data to 20Ms/s complex
    data:
    remove every other sample from the 40Ms/s sample data

  2. Frequency Translate the center frequency from 0Hz
    to 5.75MHz

  3. 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

  1. 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

2

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 :wink:

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 :wink:

Thanks,
Eric

3

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:

  1. 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

4

Eric B. wrote:

machine. Today’s machines are a lot faster than when we first wrote it.

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.

5

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!

6

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).

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.

Let me know if you’ve got any questions.

Eric

7

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 :wink:

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