Forum: GNU Radio My First HDTV screenshot from USRP

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 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 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 Mon, Apr 03, 2006 at 08:40:55PM -0400, Charles Swiger 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

Eric Blossom 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.

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 Blossom 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 Mon, Apr 03, 2006 at 09:11:37PM -0400, Marcus Leech 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