Forum: GNU Radio DVBT Tx

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
57371349a0e4580b0362a0441ef5094b?d=identicon&s=25 Vincenzo Pellegrini (Guest)
on 2007-03-05 08:18
(Received via mailing list)
Hi Eric,
I just saw your cool gnuradio presentation and heard you talking about a
not
yet realtime ATSC transmitter.
I am a telecommunication engineering student in italy at Pisa University
(Italy) at the moment, and it is quite likely that my final thesis (to
be
started in about a year from now) will be a DVB-T transmitter.

So I'm slowly approaching the subject, and starting to figure out some
preliminary choices  and possibilities...

My  first  questions  then are :

..Do you think it is possible to reach real time, considering hardware
improvements  since the video was recorded?

..How  could  I  test a non  real  time  transmitter?  (I  think  I
understand  not   real  time  receiver but how did you test the
transmitter?)


Best Regards
3d1bbca20dabfeca5cce1687c1e70660?d=identicon&s=25 Jens Elsner (Guest)
on 2007-03-05 08:52
(Received via mailing list)
Vincenzo,

I did some experiments with DAB which is, (due to differential
modulation), simpler than DVB. On the PHY level I managed to get
"almost" (about 60%) real-time performance on my P4 with GNU Radio
and prerecorded samples.

This was only PHY (even without channel coding!), and the
synchronization algorithm used was pretty shaky. Channel coding eats
up a lot of resources as well, look at the throughput figures for
gr-trellis.

DAB has a bandwidth of 1,5 MHz, DVB more than 5 MHz. All in all
considered,
my guess is that 5-8 years from now it might be possible to do these
kind
of bandwidths on a general purpose processor. But this is just my
unjustified guess. :-)

When starting to work on DVB, you'll have to write a transmitter chain
and a receiver separately, to you can test both. Just look at the
GNU Radio examples. I would suggest to limit your final thesis to the
PHY layer first - OFDM synchronization by itself is a real challenge.
What I noticed is that, due to the way transmission protocols are
designed, there is not "one solutions fits all" approach. You would
have to tailor available OFDM code to the specific needs of DVB (DAB).
A good way to start might be the new GNU Radio OFDM code available
from trunk.

A good way to "get a feeling" for real data might be to look at it in
Matlab or Octave. You could test signal processing algorithms in such
an enviroment as well.

Best regards,
Jens

> improvements  since the video was recorded?
>
> ..How  could  I  test a non  real  time  transmitter?  (I  think  I
> understand  not   real  time  receiver but how did you test the
> transmitter?)
>
>
> Best Regards
> --
> Vincenzo Pellegrini
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2007-03-05 15:28
(Received via mailing list)
On Mon, Mar 05, 2007 at 08:18:06AM +0100, Vincenzo Pellegrini wrote:
> My  first  questions  then are :
>
> ..Do you think it is possible to reach real time, considering hardware
> improvements  since the video was recorded?

I could be.  I'm unfamiliar with the DVB-T spec, so can't really offer
an opinion.  Transmitters are always easier than receivers.

One of my goals is a port of GNU Radio to the Cell processor.
I expect that we'll be able to realize about 30 GFLOPS on that
platform, which is about 10x what we can get out of a commodity PC
today.

On the Cell and with some optimization work on the ATSC tx and rx,
I suspect that both can be made to run in real time.

> ..How  could  I  test a non  real  time  transmitter?  (I  think  I
> understand  not   real  time  receiver but how did you test the
> transmitter?)

Write the generated samples to a file, then "play it back" in real time
from the disk.

With the ATSC work, we wrote the transmitter and receiver at the same
time, then looped them back at compatible places in the pipeline.

> Best Regards
> --
> Vincenzo Pellegrini

Eric
This topic is locked and can not be replied to.