discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] RDS / TMC / DAB / DVB-S/T ?


From: David I. Emery
Subject: Re: [Discuss-gnuradio] RDS / TMC / DAB / DVB-S/T ?
Date: Sat, 14 Oct 2006 13:54:16 -0400
User-agent: Mutt/1.4.1i

On Sat, Oct 14, 2006 at 06:49:03AM -0700, Eric Blossom wrote:
> The USRP could receive the raw signals for DVB-T in the 6 and 7 MHz wide
> channel format.  The 8 MHz wide version could be somewhat degraded
> because of filter rolloff at the edges of the passband of the digital
> downconverter in the FPGA.  Shifting to 8-bit I&Q would allow the full
> 8 MHz wide signal to fit across the USB at the expense of dynamic range.
> 
> I'm not sure of the bandwidth required for DVB-S and thus can't comment.

        DVB-S as used for video is usually upwards of 3 megasymbols/sec
as this kind of data rate is required to support sufficient transport
stream bandwidth for adequate distribution grade video.  Many of the
actual signals on satellite, however,  are multiplexes of multiple video
and audio streams sent at symbol rates as high as 26 to 29
megasymbols/sec.

        Currently almost all signals are QPSK (NOT DQPSK, absolute phase
counts) although the standards permit 8PSK and even 16QAM.  8PSK IS used
for some HDTV feeds (notably the US broadcast networks ABC and NBC and
the Canadian network CBC) and some HDTV backhauls.

        Roughly speaking, the actual rf bandwidth required to demodulate
QPSK is perhaps 1.1 to 1.2  times the symbol rate with a higher sampling
rate than that probably necessary to get good results.
        
        This implies that the USRP with a 6 to 8 mhz bandwidth might be
able to successfully demodulate the SCPC DVB-S QPSK video transmissions
at symbol rates like 3.9876 megasymbols/sec (5.5 mbs transport stream at
FEC 3/4) commonly used by satellite trucks for news feeds.   Most of
these signals carrying single channel NTSC video (720 by 480 MPEG 2) run
at either 3.9 megasymbols/sec or 4.2 megasymbols/sec.

        Making it demodulate the wider band signals used for video
distribution and HDTV is probably not possible, nor for that matter is
the processor bandwidth required to munch the samples any more likely
available than that required to handle ATSC (though demodulating
satellite QPSK on a nice clean linear channel off the satellite should
take MUCH less compute than ATSC with equalization and so forth).

        There are a few DVB-S signals that run at unusually low data
rates (hey it's cheap since satellite charges are based on bandwidth and
power used) down to as little as 1.6 megasymbols/sec.   And the same
basic modulation is sometimes used for sending audio streams like Muzak
for stores and restaurants at lower rates.   These doubtless could be
demodulated by the USRP.

        Obviously the back end compute required to munch sample streams
this fast is not inconsiderable - processing DVB-S requires estimating
and tracking carrier phase and recovering symbol clock and then doing
Vitirbi (k=7 trellis) on the resultant low pass filtered I and Q sample
stream.   The only good thing here is that a satellite transponder is a
benign medium with no multipath or amplitude/delay distortion to speak
of, thus elaborate FIR filters with huge numbers of taps are not needed
to compensate for this as they are for ATSC.

        As for the underlying data - many signals are in the clear
(almost all satellite truck newsfeeds are for example) and contain
standard MPEG 2 transport streams that can be displayed by existing
open source utilities.  Some others, of course, are encrypted (mostly
with DES) and not accessible.

-- 
   Dave Emery N1PRE,  address@hidden  DIE Consulting, Weston, Mass 02493
"An empty zombie mind with a forlorn barely readable weatherbeaten
'For Rent' sign still vainly flapping outside on the weed encrusted pole - in 
celebration of what could have been, but wasn't and is not to be now either."





reply via email to

[Prev in Thread] Current Thread [Next in Thread]